Resets and repops

[S001GMU at nova.wright.edu]

Date: Sat, 05 Apr 1997 11:57:07 -0800
From: 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.

I think I didn't explain very well what I was thinking.
Here's the coding sequence I was thinking of:

-- Bucket is coded in castle.  It has an internal state of "weight"

-- CT is programmed to have branches break whenever the weight on them
   becomes to great, and to get updates it installs watchers on the internal
   state, "weight", of anything that is added to the CT branches.

-- Now, the balloon:  Balloon has an internal state of "weight" which the
   designer wants to be dependant on the "weight" of the bucket in the castle.
   The balloon installs a watcher on the Bucket's internal state of "weight".

thus, whenever the bucket's weight changes, the balloon finds out and updates
it's weight, which causes the CT's watcher to go off and get the new weight
from the balloon.  I believe my previous explenation didn't quite convey what
I was thinking (not unusual).  Left out that the balloon installed the watcher
on the bucket.  I think you interpreted the watcher as belonging to the bucket,
not the balloon.  as far as I can tell, none of the above steps violates any
of your rules...

This assumes that the watcher installed by the balloon has the ability
to tell the balloon to change it's weight, which I assume is possible if the
CT can be triggered to break a branch when something on the branch gets too
heavy.

>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.  

I believe that's what my sequence above does...

>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.

The only thing that requires the balloon programmer to put the watcher on
the bucket is the desired effect of having the balloon's weight be dependant
on the bucket's.  Without the watcher, I don't know if there is a way to
do it in your system (I'd have to go re-read most of that message you sent
out a long time about how yer system works.. and I'm too lazy for that atm;).
I don't really have a problem with putting the burden of determining the
cause-effect chain on the builder.  Maybe they want a balloon that has a weight
based on the number of times someone hits the kobold automaton in the cave
under the CT and not the weight of the bucket in the castle.  Both cases would
require a different set of watchers, and you can't anticipate every possible
combination when designing the system.  ;)

<....>

>>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?

again, the only way to require it is to get builders with half a brain who
can figgure out that the cause-effect chain they are looking for is built
like so in yer system.  You have to assume SOME level of intelligence on the
user's part.  ;)

-Greg