Replacing changed/update experiment..

Peter Smet peter.smet at flinders.edu.au
Tue Jun 15 07:44:20 UTC 1999


I have finally put my event stuff through a
'change the engine while the car is running'
scenario. It involved:

-filing in the change-set with the PostOffice class in it.

-converting all exisiting dependents in DependentsFields to
have their events routed via the PostOffice.

-emptying DependentsFields

-Filing in changes to handle
#addDependent:
#changed: etc
in Object and remove these methods from Model

-getting #dependents to return a bunch of subscribers
from the PostOffice

-keeping my fingers crossed and lots of restarts.

Since the browser and many windows use the changed
update: protocol, any mistakes meant all tools became
instantly useless.

Anyway, my image is now running without any reliance
on the changed/update mechanisms. It transparently
intercepts all the calls and dispatches the messages
(events) accordingly.

I have attached 2 change sets.
Publish-Subscribe files in the event-mechanism
BUT LEAVES the changed/update mechanism intact.
This should be pretty solid :-)

The second change set (Dependents) is for those who
like to live on the edge, and throws out all the old
event dependency mechanism. I don't yet know how
effectively this substitutes for dependency, and
would like to know how people fare with it. So far
everything in my image is behaving itself...

The PostOffice system should allow many Observer-
type relationships to be simplified. methods like:
update: symbol
   super update: symbol.
   symbol == #buttonPushed ifTrue: [^self squeakLoudly].
   symbol == #buttonPulled ifTrue: [^self squeakSoftly: volume5 ].
   symbol == ....  God knows how many other cases.....

Can now be replaced with initialization wiring code like:

aSubscriberThingy>>initialize
   buttonInstance when: #pushed send: #squeakLoudly to: self.
   buttonInstance when: #pulled send: #squeakSoftly to: self with: volume5.
  etc...

  buttonInstance trigger: #pulled.
  will then route the appropriate message to any subscribers.

As has been pointed out many times, the big disadvantage of
changed/update is that every dependent is informed of every
update, and has to filter all the events to pick out the ones
its interested in. With the wiring code, the publishers essentially
'push' the correct actions for any particular event onto the subscribers.

A challenge for anybody reading this. I have implemented publishers
as a WeakKeyDictionary. For each key in publishers, its value is
itself a WeakKeyDictionary containing the subscribers as keys. This is
great from the point of view of garbage collection and simplicity,
since the structure effectively 'implodes' when references
disappear. A faster structure would have publishers as the main
dictionary, but the value would be an eventDictionary, keyed by
the event. If you reference the dictionary by:
at: aPublisher at: anEvent, you know that all the subscribers will
need to be informed. On the other hand, if you say:
at: aPublisher at: aSubscriber
the subscriber may not be interested in that event.

I would like to implement it the second way, but getting the
garbage collection right is likely to be messy..

The other challenge, which is well beyond me, is how to
deal with distributed events....

Any thoughts on this appreciated.

Peter







Content-Type: application/octet-stream;
	name="Dependents.15Jun346am.cs"
Content-Disposition: attachment;
	filename="Dependents.15Jun346am.cs"

Attachment converted: Anon:Dependents.15Jun346am.cs (????/----) (0000ABEC)
Content-Type: application/octet-stream;
	name="Publish-Subscribe.15Jun308pm.cs"
Content-Disposition: attachment;
	filename="Publish-Subscribe.15Jun308pm.cs"

Attachment converted: Anon:Publish-Subscribe.15Jun308pm.cs 
(????/----) (0000ABED) 





More information about the Squeak-dev mailing list