[DGD] First of many methodology questions

[Stephen Schmidt]

On Thu, 16 Oct 2003 nihilxaos at nihilxaos.com wrote:
> On some muds that I've seen the base user object handles absolutely
> everything about the user.

Back in the bad old days before there was DGD, the most serious
problem with this method was updating the code. If you wanted
to change (say) a command, and the command code was in the player
object, then you could update player.c, and player.c would have
the new command. But all existing clones kept the old code, ie
the old version of the command. The only way you could get the
new command to the players was to make them all quit and log back
in. Players complain about such things.

The reason to move the command to a separate command object was
so that you could update the command object, then when players
typed the command, the thread would be passed to the (now updated)
command object and would work properly. No need to force all the
players to log out and back in.

With DGD this may be less of an issue because it may be possible
to update the code of existing clones of player.c. I am not expert
in this matter and will encourage others to comment on whether
this strategy is feasible or not.

But if DGD can update code in existing player clones, which I think
it can, then that removes the main problem of a big user file. A big
object is not a problem as long as you inherit correctly, and the
rumors that big objects are slower objects are greatly exaggerated.
Larger objects are very slightly slower due to longer lookup times,
but my memory (again, experts please correct me if I'm wrong) is
that lookup times for functions and variables are order log(N) and
so it's really not a big deal. And, passing a thread to a command
object also takes time.

All that said, I prefer command objects, primarily because it
means you can edit commands without having to edit player.c.
If you make a typo and screwup give.c, then no one can use the
give command until you fix it, but for a few minutes they can
cope with that. If you make a typo and screw up player.c, then
no one can log in until you fix it, and that's Bad. Also, just
for organizational purposes I like the idea of having a directory
of commands, with subdirectories, so I can control command
access with the path structure. It also means you can allow
users who are less privileged than top administrators to edit
some of your commands. Only top administrators should have
edit access to player.c, for obvious reasons. You also need to
make sure that only top adminstrators have access to file
handling commands, but you can allow lower wizards to handle
other commands, such as guild commands.

And that said, I'm sure my preference is based 90% on the fact that,
as a longtime MudOS/TMI-2 user, I'm used to a command directory
method. Wiztools freak me out, for no good reason. Most people
who use DGD seem to be more used to the wiztool method. I'm
sure it's equally good, and it's better if that's what you're
used to, but command bins are what I'm used to, so that's what
I use.

Steve


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