[DGD]Default Wiztool not loaded ?

[Stephen Schmidt]

On Fri, 16 Feb 2001, Par Winzell wrote:
> If you implemented it using a /cmds directory, I would ask you
> what the advantage is of that :-)

Good point. I guess the main thing is that it's easier
to maintain commands if each one is in a separate file
that doesn't do anything else. I was kinda struck by the
length of receive_message in the kernel's user; it's
quite long because the basic commands (say, tell, passwd,
users, that sort of thing) are hard-coded in user.c.
If you want to change the tell command, and you make
a mistake and the file won't load, with the /cmds
system, all that breaks is the tell command. With
the kernel system, user.c would stop compiling. Similarly
with the wiztool, although if you had a clone of the
old wiztool already, nothing bad would happen as long
as no one tried to clone a new wiztool.

There are also some parsing advantages to knowing that
the code for the foo command can be found in /cmds/foo.c,
although not much, and of course there are parsing advantages
to knowing that commands are found only in the wiztool also.

I agree that command objects should not be instantiated.
In DGD it's not hard to prevent that, although Melville
does not bother.

> The 'most mudlibs'
> statement you make is, I think, both wrong and irrelevant...

Perhaps so. I should perhaps have said LPMud mudlibs and
variants, as I don't know much about other types. Within
that group, LP 3.x, TMI-2, Nightmare, and Melville use the
command file system, LP 2.4.5 and the kernel lib use the
wiztool system (IIRC - haven't used any of them except
the kernel and Melville for years). That's not a complete
list of those mudlibs either but it's the only ones I am
even passingly familiar with. Do mudlibs from a broader
category tend to use other systems? I am sure there are
more than two ways to solve the problem.

> Why -should-, say, 'ls', exist as an object? What does it do
> that it needs to be able to be referenced through an object
> pointer?
 
Nothing particularly much. The advantages, as I see it, are
being able to access it as a separate file, and are primarily
organizational. The system of having each command in its
own file, but then be inherited into user.c, would also
derive most of the benefits, except for the handling of
a failed compile.

Steve 


List config page:  http://list.imaginary.com/mailman/listinfo/dgd