[MUD-Dev] Re: DevMUD - thoughts.1

[Chris Gray]

[James Wilson:]

Again, thanks for the details. I'm now understanding what you were getting
at better.

Hmm. Any comments from others on Niklaus' or James' information?

[My stuff snipped.]

 >yes, that's the other meaning of 'dynamic typing' that I was advocating.

OK. So long as things like:

    int f(int i, j) {
	return i + j;
    }
    Print(f(1, f(2, 3));

require *no* run-time checks, then we are agreeing on the meaning of
these things.

 >modules would need to register their functionality with the dynamic loader,
 >so they could be loaded when such functionality is requested. cf. kerneld,
 >which requires you to run depmod first.

Ah, OK. That wasn't clear to me. I know there is a kerneld running on
this computer, but that doesn't mean I know what it actually does!

 >>I understand the C++ syntax you have written (except for "/* rep */" - is
 >>that just meant to copy the prototype?), but I'm completely failing to
 >>see what you are getting at. Sorry.
 >
 >Writing it as a straight function call makes it impossible to extend by
 >subclassing, whereas using an object makes it possible.

Sorry, you've lost me again. I don't know what you are saying.

 >Why would a handler want state? It seems to me that in a persistent
 >>virtual world, all state should either be attached to the entity
 >>(e.g. player character) doing the action, or be global state attached to
 >>some other persistent entity in the virtual world.
 >
 >*blink* why is that inconsistent with a handler having state? suppose I
 >wanted to write a persistent object that WAS an inputHandler? or do you 
 >mean REALLY global state?

I'm not trying to be difficult here, really, I'm not! But, shouldn't an
inputHandler (whatever that is - I thought it was something that was going
to, say, parse a user input command and then call out to scenario stuff
to handle that command) be usable for any number of inputs from various
sources? Are you suggesting there be an inputHandler object (or whatever)
that is attached to a specific input source like a player character or
NPC? In that case, then I claim that the state is part of the state of
that character. Having it be a separate entity in the persistent database
is a minor detail. However, that being the case, you need to have stuff
setup so that that state is actually saved/restored as needed. Thinking
of the state as part of the character state immediately suggests that it
is saved/restored with other character state. It wasn't at all clear to
me what the semantics of your "inputHandler" state is.

 >this would assume that there's a distinction between DB objects and in-memory
 >objects, no? that is an issue which AFAIK hasn't yet been raised or
 >resolved.

Guilty as charged. I was assuming that. I was (and still am) assuming that
temporary structures, which exist only for the duration of an in-server
operation or connection, have no need to go anywhere near the persistant
universe.

In your discussion of 'inputHandler' it sounds like you are assuming that
all state is persistent automatically, and that there is a link between
an inputHandler and the source who's input it is processing, and hence
saving state about. Is this correct, or am I still missing something?
(Maybe that's too strong - but it does seem that you were assuming that
the state of the inputHandler is automatically persistent, but I didn't
see anything indicating that. Hmm. Either that or your weren't assuming
a fully persistent universe - I'm guilty of assuming that's what we
all want.)

 >agreed, though I would again write that as fields in some object rather than
 >as static, so one could have multiple telnet servers running
 >simultaneously.

OK. That would allow you to have an experimental one being debugged, and
a real one for players to use.

 >>If some modules wish to use shared libraries, that is up to them. 'dlopen'
 >>can take care of that. It is outside our concern. What I think we need is
 >
 >no no, the analogy is that modules ARE shared libraries.

Well, at the system level, they need to be whatever the system requires
them to be in order to be able to load them. But, if we don't need to
think of them as just shared libraries, why do so?

 >>ways whereby, e.g. modules that provide user input/output to the system
 >>can be linked up to modules that provide parsing, scenario code, and
 >>database operations. That linking up isn't done by name, it is done
 >>based on the semantic nature of what is needed.
 >
 >how is this semantic nature determined?

Its determined by module implementors when they decide they need it.
I guess I'm the one being more abstract in this case. How modules get
in communication with each other is an implementation detail. It could
be via names passed to 'dlsym', or it could be something more like
Niklas described.

 >this is not an issue with C++ or suitably name-mangled C.

Sure, just have the interface 'kind' be part of the name.

 >>James, it seems to me you are thinking of building modules that are
 >>aware of each other at compile time. I've been trying to avoid that,
 >>so that only at run-time are they actually attached to one-another.
 >>But then, I could be missing your point altogether. How about a
 >>more detailed example?
 >
 >I guess I don't see the alternative to having modules know about one
 >another at compile time. Either they refer to some external symbols
 >(which end up being function pointers or objects with virtual methods)
 >or ... what? No module refers to any external symbols? All function 
 >calls are done by (a stringified) name?

No, all function calls are done via function pointers. The values in those
pointers are setup by the DevMUD core as part of the module loading.
See the stuff that Niklas posted.

 >you're not coming on strong, at least in this message. and besides, what's
 >wrong with a little debate? we're not delicate little flowers.

"Little Weeeeeed?". I'll bet nobody on the list understands that reference,
to an old English children's magazine entry that later became a short TV
series. Anyway, that's what your mention of little flowers brought to
my twisted mind!

--
Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA