[MUD-Dev] Re: PDMud thread summary

Niklas Elmqvist d97elm at dtek.chalmers.se
Mon Oct 26 00:22:18 New Zealand Daylight Time 1998


On Sun, 25 Oct 1998, James Wilson wrote:
> On Sun, 25 Oct 1998, Niklas Elmqvist wrote:
>
> >class CallPipe : public Pipe {
> >private:
> >	FunctionPtr *hFun1, *hFun2;
> >public:
> >	..
> >	virtual void Send(ModuleID hSrc, ModuleID hDst, Message *hMsg);
> >	virtual void Recv(..)
> >	..
> >}
> >
> 
> [other kinds of Pipes snipped]
> 
> thanks for the example, it made things much clearer. the pattern
> here is asynchronous message-passing, as found in, for instance, 
> PVM, which is well-suited to highly decoupled parallel systems. 
> If this is what people want, PVM already does this beautifully and
> there's even a distributed FS for it. 

Well, I would argue that there are other servers which do MUDs quite
beautifully. Why do we need DevMUD, then? 

> However, message-passing like this adds considerable programming
> complexity to simple operations. Every function call into other modules
> has to be done as Send and Recv pairs, where the next Message Recv'd
> isn't necessarily what you wanted: 
> 
> /* try to get object 'foo' */
> 
> g_mainbus->Send (module_a, DB_MODULE, /* deliver foo or else! */);
> Message *gotfoo = g_mainbus->Recv (module_a);
> 
> /* simultaneously, in some other meddling module... */
> 
> g_mainbus->Send (module_meddler, module_a, /* you go to hell! */);
> 
> so, back in module_a, we get 'you go to hell!' instead of 'foo'.
> Checking this on EVERY FUNCTION CALL would get quite tedious
> and add a performance hit. Moreover it's more prone to breakage
> by newbie module-programmers for whom parallel systems are
> mysterious.

Okay. I see your point. But if we want distribution, we need this anyway.
*shrug*

And yes, I am starting to hear your arguments here. I always thought a
pipe-like mechanism would be a very nice O-O abstraction for my own MUD
(although I at first envisioned something Chris Gray so aptly named "water
sprinkler"), but what you are saying is starting to make sense. The moral
of this story is: "abstraction is good, but to a degree only", a slightly
revamped version of my initial statement. 

But please let us contain function pointers as function objects. It
not only looks cleaner to my O-O sensitive eyes, that way, we can also
easily subclass them and add state for some reason. (Of course, since I
have not thought this through, I may be rambling :)  

> I fully agree that abstractions are important. This seems like rather
> an extreme way to do it though, which to me is only really justified
> in a distributed system.

Agreed.

> James

-- Niklas Elmqvist (d97elm at dtek.chalmers.se) ----------------------
  "The trouble with being a god is that you've got no one to 
   pray to."
		-- Terry Pratchett, Small Gods





More information about the MUD-Dev mailing list