[MUD-Dev] Re: PDMud thread summary
Niklas Elmqvist
d97elm at dtek.chalmers.se
Mon Oct 26 00:22:18 CET 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-archive
mailing list