Another verb move for the 25Dec95 core

• Date: Thu, 4 Jan 1996 15:58:59 PST
• From:
  Judy Anderson <yduj@cs.stanford.edu>
• 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

• 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