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

[clawrenc#cup,hp.com]

In <199706260440.VAA06955#pc4,zennet.com>, on 06/25/97 
   at 09:47 PM, "Brandon J. Rickman" <ashes#pc4,zennet.com> said:

>On Mon, 23 Jun 1997, Shawn Halpenny <malachai#iname,com> wrote: 

>An aside--given:
>>Room R at time t=0.
>>An earthquake is scheduled to occur in R at t+5.
>>Room R is spoofed at t+2, creating R' which now exists in lieu of R.
>>Time t+5 arrives, the earthquake occurs.  Are the effects of the
>>  earthquake applied to R, R', or both?  Generalized:  are any
>>  actions occuring on R to be duplicated on R' and vice versa?
>  
>>Note:  the spoofing of R and the earthquake are independent events
>>and are completely unrelated in cause, execution, and effect.

>This is a great example of a particularly bad (and quite common) way
>of non-atomic coding.  "Scheduling" an event in this case is like
>declaring a prophecy: "There will be an earthquake in 5 ticks!"

Why do you define this as "bad"?  Given that you need to change the
semantics of the sceduled event from "There will be an earthquake at X
time," to "Decide at X time if there will be an earthquake then," I
don't see a problem (ie this is what I've been doing without trouble).

>I'll go out on a limb and claim that events must always immedidately
>originate from objects.  There should be no indirection of events,
>such  that an event might be scheduled by an object but actually be
>originated as a server action.

>In the above, R (for all practical purposes) is the originator of the
> earthquake.  But by scheduling the event at t+5, R has added
>indirection. Now at t+5 either the server emits the event only to R
>and no one sees it, or the server looks for R, can't find it, and
>dumps the event.

Yup.  An event is actually a message: a method call with a particular
payload in the form of arguments.  Its not to be seen, its to be
reacted to, thus causing effects which may be seen.

>I'm thinking cold-like frobs provide a way to solve this.  

Frobs?  How so?  

>Otherwise
>a tighter way of relating the spoofed object to the object of
>spoofing is needed.  Then R gets the event and passes it on to it's
>spoof.  This would need quite a bit of garbage collection.

See my prior discussion and definition of spoofs.  Its all handled
automagically -- there is no necessity for garbage collection or other
clean ups.  The spoof merely adds an automated form of indirection and
filtering.

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