[MUD-Dev] C&C and Event Rescheduling

[Shawn Halpenny]

Jon A. Lambert wrote:
> 

[ determining objects who have been written to ]

> > A change counter seems cheaper.
> 
> Hmm, could even be a 8-bit wrapping counter on each attribute/method
> forming a object signature string of sorts.

Just have to make sure your counter has enough bits that an event making a
lot of changes to an object (yes, this shouldn't happen if everything goes
according to the "small as possible executable unit" plan) won't
wrap it in one transaction.  It would be a nasty little bug when you get
bad successful commits because your before-counter happened to match the
after-counter.

[ state change notification elided ]

> In my language/VM model:
> 
> 1) Event = application consistent transaction as defined by the mudlib
>    coder.
> 2) Events are initiated whenever a event method is called.  An
>    event method call is pushed onto the execution queue and control
>    resumes to the next statement within a given VM stack.  Thus event
>    method calls do not "block"  and never return.
> 4) Event methods may call any number of regular methods or event methods.
> 5) Native server methods exist of both types and the reverse is also true
>    The server provides interface usable by mudlib coder.  'class character
>    implements user { bleh }' (BTW thank you Java for this useful concept)

You'd mentioned in an earlier post about a distinction between regular and
event methods.  Could you explain the distinction (and what it does)?  Is the
distinction explicit within the language or determined dynamically?
Do all your events cause code to be called?  How is that code specified?

--
Shawn Halpenny

"I got food poisoning today.  I don't know when I'll use it."
                                            - Steven Wright