Resets and repops

[coder at ibm.net]

On 31/03/97 at 10:31 AM, S001GMU at nova.wright.edu said:
>Date: Fri, 28 Mar 1997 11:01:23 -0800
>From: claw at null.net

>>-- The containment methods for the CT install watchers on everything
>>that gets added to them. -- The watchers trigger on any state change
>>to the watched object. -- Should the watched object leave the CT, the
>>watcher deletes itself. -- The watchers monitor the sum weight of the
>>objects, and report that to the CT on each state change for
>>appropriate handling. -- Thus *any* action which directly affects an
>>object in the CT will trigger a watcher, and result in the desired
>>action. -- Problem: an object whose reported weight is dependant on
>>the state of a remote object.  (eg the weight of the ballon is
>>proportional to the total weight of a bucket in the castle.  Add rocks
>>to the bucket in the castle, and the balloon gets heavier. This is not
>>so easy to solve if the ballon is written to determine its weight only
>>when its is queried.)

>just put a watcher on the bucket and have it update the balloon's weight
>when the bucket's weight changes, or send a signal to the balloon telling
>it it's time to change it's weight.  

No can do.  This requires the CT to somehow know about the balloon's
indirect weight dependancy on the bucket.  This violates several base
principles in my server, the primary of which is:

-- Any feature must be able to be programmed on any object without
requiring source access (and thus knowledge) or other prior-knowledge of
any other object.  

Ie All objects are total black boxes outside of their published API's.

Consider the following coding sequence:

-- Bucket is coded in castle.

-- CT is programmed with the weight breaking branches.

-- Balloon is coded with weight dependancy on bucket.

Using your comment on the bucket informing the balloon or CT, just how is
the programmer of the balloon above going to do this without having to
know something about the CT?  Remember: no changes to the bucket's or CT's
code are allowed.

Note: An easy but un-enforcable solution to the above is to have the
balloon install a watcher on the backet, and thus recalculate its own
internal weight whenever the bucket state-changes.  This allows the CT
without any prior knowledge to just install watchers on all its contents
which check for weight violations.  

The problem with this of course is that there is nothing that requores the
baloon programmer to put a watch on the bucket.  In fact, its a lot
easier, and arguably more efficient, for him to only have the bucket
recalculate its own weight when it is queried.

>It seems a bit silly to have a
>cause-effect chain set up and then try to get info from the affected
>member without going thru the chain (IE: set up the balloon to only
>calculate it's wieght when it's asked to w/o having the bucket ask it to
>whenever the bucket's weight changes).

These are the problems of free user programming.

>thus dropping a rock in the bucket would trigger the balloon to update
>it's weight which would trigger the tree's watcher to recalculate
>everything and see if Bubba falls out of the tree. Cause-effect,
>cause-effect.
>
>would be pretty cool to watch from the castle.. 
>
>*plunk*
>..
>*distant KAAARRASSSHH*  followed by "#$@%#$^$%^" from Bubba

Yup, but how do I require systems to be built that way?

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...