[MUD-Dev] Spoofs

[Eli Stevens]

I have a question about spoof implementation, as described relating
to JCL's scenarios.  For those of you who haven't heard of them
before, here is a link to the archives with some spoof description /
background (again, the message is long, and the parts I discuss are
near the end):

<URL: http://www.kanga.nu/archives/MUD-Dev-L/1997Q3/msg01198.php >

--<cut from above >--
Its easiest to diagram:

  Object A exists.
  Object A is spoofed:
    Object A is copied, creating Object B.
    Object A is deleted.
    Object C is created with the exact same ObjectID as the old
ObjectA.

Variation:

  Object A exists.
  Object A is spoofed:
    Object A is copied, creating Object B.
    The contents of Object A are deleted (all methods and attributes).
    The contents of the spoof objects are copied into Object A.

Both have the same result: the spoof takes the place of the original
object.

I then allow spoofs to have a "generic method".  Simply put, a generic
method matches any and all incoming calls/messages (I'm message based,
not stack based).  This allows a spoof to accept ALL incoming messages
and then pass them on (edited or not) to the original object (Object B
above), and then forward the (possibly edited) results back to the
original calling object.
--<end cut>--

Now, my question:

Is there any difference from implementing the above in a literal
manner (object swapping / backup, replacing ObjIDs, etc.) and having
the base game object be an inert lump with two abilities; a) the
ability to not respond to an input; and b) the ability to add /
remove other, more interesting abilities...?

_Everything_ would be done with "spoofs" - but the spoofing would be
an internal process, rather than an external one (the game object
knows about spoofs, knows when it has been spoofed, and is
responsible for maintaining or removing the spoof at the direction
of that or another spoof.

Spoof, spoof, spoof.  There.  Sorry.  ;)

Might I run into problems with this approach?  Are there hidden
benefits to interpreting the description in a more literal manner?
Or is the quoted description more conceptual in nature than I am
assuming?

Thanks for any help or insight, :)
Eli

--
Never use brute force in fighting an exponential.
      -- Andrei Alexandrescu, "Modern C++ Design"


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev