chapter 7 "Advanced Topics"

Section I: Shadows
------------------

    Shadows are a problematic topic. My first impulse is to warn
you sternly not to mess with them, they shouldn't be used, etc. In
his legendary LPC text, Descartes goes so far as to say he hasn't
seen a shadow do something that couldn't be done better another way.

    So, be aware that the topic of shadows tends to generate 
strong opinions. 

    Shadows *are* hazardous pretty much by definition. A shadow
is an object that effectively "wraps" another object, like an
invisible shadow around it. When a call is made to the shadowed
object, the shadow intercepts that call. 

    What the shadow does with the call is up to you. It can
do nothing at all, and simply pass the call along to the
shadowed object. It could block that call. It could manipulate
that call and send the modified version to the shadowed
object.

    You can see an example of a shadow in /secure/npc/drone.c .
This is the code that enables you to take control of an npc
with the remote control. The remote control loads /shadows/drone.c
which inherits /secure/npc/drone.c , and attaches that shadow to 
the npc that is to be controlled. This is a way of "adding
functions on the fly" to an already-loaded npc.
    The drone shadow is in the lib as an example
of how shadows work, and an example of how to get an object to
posess functions it did not have when loaded. It is not
intended to represent shadow advocacy.

    The danger, and the reason some people go ballistic
when they hear the phrase "I think I'll use a shadow for that"
is that a lib that allows unrestricted shadow use 
effectively has no security at all. You can have creators
enshadow an arch for example, or enshadow other privileged
objects.

    Dead Souls shadows are pretty tightly restricted. The
master object does not permit a shadow to be created unless its
code is in /shadows . This means creators can't hide their
rootkit shadows in their homedirs and expect them to work.

    Further, because /shadows is outside the /secure dir,
it serves as an obstacle to defeating the stack security
model. 

    In any case, I strongly recommend you avoid using them
except in the extremely unusual case of a task that has
no other solution. If your mud starts collecting a bunch
of shadows out of laziness, sadness will likely be the result.


Section II: The "class" Data Type
---------------------------------

    In 1995 Beek added a data type to MudOS: class.
I have to admit that I'm at a bit of a loss to explain classes,
because I am not a C guy, I'm an LPC guy. For people who
grok C, the class data type is a natural and elegant solution
for organizing related sets of variables.

    I have nothing but respect for Beek and the leet programmers
who built MudOS, so please don't go running around saying I'm
dissing them.

    But in my experience, the use of classes generally serves
the purpose of obscuring code and making it more difficult
to debug.

    I've seen newbie LPC coders take to classes like fish to water.
I can't explain it other than to speculate that for some people
the class data type (I've even had people argue at me that it's
really a "data structure", like I have the slightest clue what
the difference is) Just Makes Sense. If you are one of those people,
then bully for you. I'm serious. I don't understand you, but
your thing probably works for you, so, right on.

    However, I do not recommend that the average newbie coder
spend too much time on classes. You'll have plenty of opportunity
when you start dissecting the lib, but my friendly advice to
the noob is to use mappings instead. I've yet to see a class
do something that a mapping couldn't do with greater clarity.


Section III: add_action
-----------------------

    Yet another topic with potential for violence. The passions
can run high on this one, and in fact, the Lima team felt 
strongly enough about it that they don't enable it by default.
No add_actions by default. That's hard core.

    add_action is an efun that LP muds originally depended
on for most kinds of user input. If you wanted to be able to
throw a ball, that ball needed an add_action for it. You'd
have that ball provide a user with the throw command whenever
the user came in proximity to the ball. You can see the syntax
for add_action by examining the /lib/shop.c file.

    It's simple. It works. I mean, really, It Just Works, and 
it's the fastest way to add functionality to any object. People
used add_action from pretty much the genesis of LP, as far as
I can tell, and it became just a way of life. That was just
how it was done. Yes, that wording was intentional ;)

    However, there were serious problems with this parsing
scheme. Basically it let any creator, regardless of skill
level, define commands for the mud. Joe's throw add_action for
his ball could be poorly coded and worded, and was liable to
behave differently from Jon's version. 

    And suppose you held two or three items that had a throw
add_action each? Which one took precedence? What if that
one was bugged?

    Using add_actions for general lib command functionality
is really problematic for this reason. It fosters a lack
of uniformity across the lib that can leave users basically
playing a "guess the syntax" game for any item like this,
and allows for conflicts by incorrectly coded items. The
natural language parser was the MudOS solution to this problem,
implementing the verb system with which you are now so
familiar.

    The controversy boils down to preference. For some people,
add_action is just How It Is Done, and you still have
people starting muds with libs like Skylib and TMI-2 (!!)
that lack an advanced lib-wide parser. For these people,
verbs are an overcomplicated mess that they just don't
have a need to understand.

    Then you have the people who find add_action anathema, and
simply an unacceptable vestige of a more primitive form of
mudding. These people view add_actioners as atavistic knuckle-
draggers, either too dumb or too pig-headed to understand the
beauty and majesty of natural language parsing.

    My view, predictably, is somewhere in the middle. Verbs
*can* be exhausting to accommodate when you're just Trying To
Do One Thing. But add_actions truly are of limited use in
a modern lib, and allowing their proliferation out of
laziness is probably a bad idea.

    That isn't to say there isn't a place for add_actions. Dead
Souls supports them, and you'll see them every now and then. 
In fact, technically, every command you issue, verb
or not, is evaluated by an add_action in the mud shell object
(LIB_NMSH). It is nevertheless better to learn to use verbs, because
they eliminate many problems you don't need to reinvent the
wheel for.

    I had one person tell me, as they chose a MudOS lib that
didn't use verbs, that they planned to write their own natural
language parser in the lib. I bade him good luck. I wonder
how he's coming along these days.


Section IV: Thoughts on MudOS
-----------------------------

    Like, wow. MudOS. You know?

