[MUD-Dev] Re: Why modules? (Was: Inheritable modules)

[Jon A. Lambert]

On 31 Oct 98, Ola Fosheim Grostad wrote:
> "Jon A. Lambert" wrote:
> 
> > Why couldn't each module implement it's own desired level of
> > threading.  The loader would dynamically load the module and then
> > start it running using a createthread(), startthread() mechanism.
> 
> Can someone please explain WHY dynamic loading is desired?  I haven't seen
> one good argument yet for why it should be dynamic.  People won't replace
> their magic module twice a day. Probably not once a month either, a reboot
> once a month is quite good!

I think it's essential for bytecode modules that use the VM engine.
As for native code modules, should one be required to edit 
the makefiles and relink the entire mud statically to effect a 
change?  I can compile and link native modules independently.
I can distribute my native module in binary form to another DevMud 
user, who can simply add a few parameters to a configuration file 
and, viola, they're using my module.  

> Here are some good reasons for making it static:
> 
> 1. easier to implement
> 2. more portable
> 3. faster
> 4. more likely to be reusable in other (non-DevMUD) systems
> 5. allows for GLOBAL compiler optimization (on SGI for instance). This
>    could be an advantage if you have a lot of traffic crossing object
>    file boundaries.

On some platforms dynamic load libraries are very much preferred. 
With dynamic loading, an implementor need not even own a compiler, 
just a bunch of binaries.    

> Someone pointed out that function pointers are slow, that is not my
> experience, but function pointers effectively turns off optimization
> (inlining etc).

If there's any sort of message passing implementation, then yes, 
inter-module inlining is impossible.  Inlining within a module would
still work.

> Maybe a 20% speed up isn't all that much, but have 4 levels of 20% speed ups
> and you'll have a 100% speed up!

Yeah.  If I had to weigh the overhead of many discrete function calls 
and quite readable and understandable code versus speed and 
optimization, I'd take readable code almost every time.  But you are 
quite right, inlines give you the best of both worlds.

I guess this hit is directly proprtional to the amount of 
inter-module traffic.  Which is sort of an unknown at this point.
Some prototypes of the different ideas would be helpful. 

[snipped wrapper stuff]
 
> I think you are getting somewhere, except I don't believe that the
> interfacing can be generic if modules are to be fully reusable.  The weird
> thing about DevMUD so far is:

If you mean reusable outside of DevMUD, then one just calls the
functions like any other .dll.  Within the context of use within 
DevMUD, the wrapper or some other mechanism of indirection 
would be used.

> 1. there is no object model

Yes,  I know this does bother me a lot.  I think there are many
disconnects here between those of the function/data persuasion and 
those of the object-oriented persuasion.  

> 2. interfacing is generic

I think a common protocol was desired.  Generic to me implies
easily replaceable with another module that implements similar
functionality, but perhaps in an entirely different way.  Or
modules which expose Facades which are particularly useful to
the application at hand.  Wrappers could be customized to only
expose the particular functionality the server author needs.

> 3. modules are reusable

see above?
 
> This doesn't make sense. Something has to patch things up. If some entity is
> to be reusable then somebody else HAVE to know more than the others.  I
> don't believe that one can have an all-bottom no-top system?  

That's why I've made an attempt at describing an all-top system.  
I admit it's neither formal nor a good attempt.   In fact it's been 
highly critiqued by J. Wilson.  Which I think is a very good thing.
I need to go back, rethink it, explore some prototypes and perhaps 
make a more rigorous attempt at definition.

--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--