[MUD-Dev] Room-based vs. coordinate-based

[Shawn Halpenny]

clawrenc at cup.hp.com wrote:
> 
> In <339C618C.167EB0E7 at iname.com>, on 06/09/97
>    at 05:16 PM, Shawn Halpenny <malachai at iname.com> said:

[ original handling of user-programming ]

> You're going to have a checklist to run every piece of code past to
> make sure nothing has been missed?  You're never going to skip or
> skimp something on this list?  This list is going to always be updated
> as the system changes?
> 
> >The solution above is not exactly conducive to that.
> 
> Quite.

_Originally_ that was my intent, though the more I thought about what I
wanted to be possible, the less I looked forward to the amount of work
involved.  So no, there won't be any checklist that I have to watch over,
since if I can make things generic enough, everything will hold itself
together and not need me to hold its hand.  The addition of user-programming
was a fairly recent thing for me, so some changes of methodology are
definitely necessary.

[ spoof implementation ]

Which is essentially what I'm getting at here:

> >I make the magic-effect creator a method on a container (say, a room)
> >and whenever I want to "spoof", I just override the method in a
> >derived object (something I already do elsewhere, hence my realizing
> >I'd not thought the post through enough).  Simple enough, since all
> >the rooms are derived from a common object (which would have been
> >that magic-effect creator if you went high enough up the inheritance
> >tree) anyhow.  That should now account for stupid programmers and
> >make things much more scalable.  And of course, if one does the
> >inheritance and overriding properly, it's nicely applicable to all
> >sorts of other situations.
> 
> Bingo.

Good.  Nothing new or quirky going on here, just plain OOD.  What I called
"inheritance" is your spoof-by-cloning, and your generic methods are what
I do through overriding.

> >If A wants to watch B, A sticks a reference to itself in a list
> >inside B.  State changes in B will now send notification to A
> >provided the change matches the parameters required by the watcher.
> >A can stop watching B whenever it chooses, but only the destruction
> >of B can force A to stop watching B.
> 
> Ahh.  I don't have any sort of filtering or definition of watchers.  A
> watcher just triggers whenever an object changes.  The result is a
> message sent to the waiting object of the form, "I HAVE CHANGED".  I
> then leave it up to the waiting object to figure out what changed, and
> if they are interested in that change.

A watcher will only trigger if the correct property (or properties)
changes so that the watching object isn't deluged by messages about state
changes it doesn't care about on busy objects.  The waiting object only has
to decide what to do with the change, since it only gets messages
concerning the things it cares about.

> This allows a watcher to trigger on a state change for a private data
> member in an object.  Depending on the strictness of your views on
> data encapsulation, this can be thought of as a Good Thing, or a Bad
> Thing.

Watchers can trigger on private data changes by not defining exactly what
they're watching, but choosing to watch for a change in any property.  So
I still maintain the low message traffic for watchers waiting on a few
properties, and don't have to cheat my encapsulation by allowing watching
on the entire object if desired.

--
Shawn Halpenny

"Caesar si viveret, ad remum dareris"
                            - Latin for All Occasions