[Prev][Next][Index][Thread]

# Another verb move for the 25Dec95 core

- Date: Thu, 4 Jan 1996 15:58:59 PST
- From:
- cc: moo-cows.PARC@xerox.com
- In-Reply-to: "Stephen Sayer's message of Thu, 4 Jan 1996 03:17:31 PST <ML-2.0.820754251.7349.ssayer@voyager.hijinx.com>"
- Posted-Date: Thu, 4 Jan 1996 15:58:59 -0800 (PST)

       From: Stephen Sayer <ssayer@hijinx.com>

       Judy et al.,

       Based on the existing character hierarchies I decided that I should @set
       $player_class to #90 (Frand's Player Class) instead of #6 to fix the $login
       problem.

       Generic Guest, builder, programmer and wizard are all descendents of that
       class so I resolved that regular players should be too. There are quite a
       few verbs and properties defined on the intermediate Generic Mail Recieving
       Player and Frand's Player Class that I found to be compelling reasons for
       the action I took.

       Is there some reason why my approach isn't a more appropriate change to
       make?  I'm still wondering what if any side effect might result from my
       change and how the fact that I've left $player set to #6 will affect things
       too. Especially since the line from the wizard verb...
       #56:make-core-database [Wizard (#2)]: $player_class = $player; ...equates
       these two when a core is generated. But perhaps I'm only looking at the
       source of the problem. I've been running a JHCore until I grabbed the new
       LambdaCore so I'm still feeling my way around it a bit. If my approach is
       valid should I also change $player similarly?

    It is always appropriate for a MOO administrator to make the choice of
    what the default player class shall be for that MOO.  This choice is
    made by setting $player_class to a useable class in the player
    hierarchy; indeed it may be a specialized player class made for that MOO
    that isn't part of the original core.  Changing the value of "$player"
    is never right---that is just the name for #6.  $player_class is the one
    that should be dynamic.

    However, the original complaint was that :confunc on $player required
    properties which were defined on $mail_recipient_class, and indeed, that
    is a bug---you may be *unaffected* by the bug by virtue of choosing a
    default player class higher in the hierarchy, but it is still a bug, an
    inconsistency in the programming.  My proposal fixed that inconsistency.

          Judy Anderson yclept yduJ          'yduJ' rhymes with 'fudge'
     yduJ@cs.stanford.edu (personal mail)   yduJ@harlequin.com (work-related)
    	Join the League for Programming Freedom, lpf@uunet.uu.net

References:

- Re: Another verb move for the 25Dec95 core

- From: Stephen Sayer <ssayer@hijinx.com>

- Prev: Re: Another verb move for the 25Dec95 core
- Next: Backspace...
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index