[MUD-Dev] Re: Issues from the digests and Wout's list

[clawrenc at cup.hp.com]

In <199704270722.CAA25667 at dfw-ix7.ix.netcom.com>, on 04/27/97 
   at 07:50 AM, "Jon A. Lambert" <jlsysinc at ix.netcom.com> said:

>> From: clawrenc at cup.hp.com
>>    at 11:03 PM, "Jon A. Lambert" <jlsysinc at ix.netcom.com> said:

>> >While I love the use of regular expressions in COLD, the enhancements
>> >they have made to context are decidedly irritating.  One's order of
>> >verb processing can easily change by moving about the world and
>> >picking up and dropping items.    I prefer a consistent and fixed
>> >context order. It makes for a more comfortable user interface.
>> 
>> Mind detailing exactly what you like and dislike about their changes
>> to the definition of context?  (Been a while since I looked)
>>

>This is in the ColdX core.  There is a dictionary called "context"
>attached to the $user object.  The command_parse searches this
>dictionary for best(?)  matches when one uses a verb that could be
>used with multiple objects. For instance,  the "look" command's
>context might not be resolved to the  current location as one might
>reasonably expect assuming a missing direct object.  It can be
>finally resolved as "look Bubba" by picking up an object who's
>methods insert entries into the user's context dictionary.    

>An interesting side effect for sure.  We had discussed earlier the
>prospect of players perverting other players namespaces.  This brings
>up the problem/ feature of objects and locations perverting a users
>default context search in their command interface.

Unfortunately I don't have the time right now to go research this
directly, so I'll pick your brains instead... <kof>

As I read this, it would only actually affect the parsing context when
a verb was hit which had multiple possible resolutions.  No?  

AFIAR ColdX uses the following parse order:

  character
  inventory
  room
  local objects (inventory of room)

Do they make this decision of ambiguity (and resultant scan of the
context dictionary) at each level of the tree, or only once the full
tree has been traversed?

What are the rules for defining and manipulating the context
dictionary?

>A key OO concept is blurred here.  The distinction between class and
>object instance.   In Cold this has led to the $frob and what I would
>call the prototype object or more properly the class descriptor
>object.   

I've never liked ColdX's frob concept.  It seems a real hack in an
attempt to reverse bolt-on a coupound type.

Yup, AlexO and I argued about this class/instance difference point for
a long time back in the original CC: list.  At that time I was talking
the stance that there was no real need for a distinction between class
objects and instances.  Since then I've reversed -- mostly due to the
fact that without the distinction management of state between classes,
instances, and new instances can be a big problem.

>For example there exists a $connection object which
>contains all the methods and attributes necessary for handling a
>socket  connection.  When a new connection is made a new object is
>created that inherits $connection instead of an instance of
>$connection. Instancing is can only be done through inheritance.  

This has some advantages in providing runtime morphism.  The problem
is see with ColdX is that they have taken this one idea and turned it
into a hobby horse with which to solve all problems.  There are some
definite elegancies with instancing via inheritance, but there are
also some big uglies.

>The
>inheritance tree depth can easily double and since methods can be
>protected, private  or public the "instanced" object is not
>neccessarily like the object that spawned it (and attribute variables
>also since the last release) 

Yup, this is a mess.  I took one stab at introducing
public/protected/private methods and inheritance and ran away
screaming at the repercussions.  I still have public and private
methods, but that only affects their visability to external messages,
not inheritance.

>Now all of this is not necessarily a bad thing, but it does require a
>significantly different approach to implementing an OO design than
>other OOP languages.  

Agreed.  I'm pretty solidly in the Cold camp at this point for the
inheritance/class/instance design except tht I have formally seperated
classes and instaces.  The rest I'm still exmaining.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...