[DGD] First of many methodology questions

[Noah Gibbs]

--- Stephen Schmidt <schmidsj at union.edu> wrote:
> Back in the bad old days before there was DGD, the
> most serious
> problem with this method was updating the code.

  As you speculate later, DGD removes this problem. 
You can update the whole user object in-place without
a hitch.  You can also update any module in-place
without a hitch.  So both ways do this perfectly now
if your upgrade code works.  Phantasmal's, for
instance, does this just fine.

> 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.

  This is correct.  Again, I believe that the cost for
modularity will actually make a large user object
*faster* in almost every case.  However, the total
difference is so small that you should ignore it.

> 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.

  Yup.  What he said.  This is one reason that I'm
working to make Phantasmal more modular.  When I screw
up the socials file, nobody cares.  When I screw up
player.c, I may not be able to log in to fix it!

> 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.

  I'm actually against this, but I prefer to control
command access in the command code and with keywords
or attribute bits.  Matter of personal preference. 
His way works much more painlessly for simple
differences, my way extends better to complicated
stuff.

> It also means you can allow
> users who are less privileged than top
> administrators to edit
> some of your commands.

  This is a big one.  It's one more reason I'm working
on more modularity.  Letting random admins add new
socials is a fine idea.  Letting them edit abusable
commands like "give" and "say" is less secure.

  I handle this by having configuration files for
certain commands.  For instance, social commands use a
text configuration file.  The cmd_social() function is
still off limits to everybody but implementors, but
lesser admins could edit the existing social file
and/or add new social files.  However, it's also nice
to be able to let other admins write actual code, not
just text config files.  I'm working on that -- DGD
actually has some pretty cool sandboxing facilities if
you know how to use them.  I've never seen anything
really use them, though.


=====
------
noah_gibbs at yahoo.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd