Hello Subbu,

> Good stuff. You should add it to squeak wiki so that you can directly link
> terms to their wiki entries.

thank you very much. Putting the text into the squeak wiki is on my todo list. 

Also, thank you for your clarifications on the different usage scenarios. 
Unfortunately, I think I do not fully grasp why CU events are easier for 
unknown listeners. All that a change from CU to WS events seems to require is 
maybe a relocation of the registration code(?)

[Note that my text is meant as a description of what is, not of what should 
be. What was/is important to me, is to document that several mechanisms exist 
so that people don't end up looking for errors in the wrong places.]

Suppose we have a viewer as you proposed. When a value in the viewer is 
changed,
- with CU events, viewer would issue "self changed: #valueUpdate";
- with WS events, viewer would issue "self triggerEvent: #valueUpdate".

> For instance, when up key is pressed in a list, the listener is well known
> and interested only in the happening of key press. WS is ideal for this
> case. On the other hand, when a value in viewer is changed, an unknown
> number of watchers need to read the new value. This would be a case for
> changed/update. Of course, we could use a WS when the watcher is created
> but it wouldn't be simple.
Why is it more complicated? At some point you have to tell the watcher which 
viewer to watch. So couldn't you just have a method

Watcher>>watch: viewer
    viewer when: #valueUpdate send: #doSomethingWatcherSpecific to: self

that is called during initialization (or maybe later)? It certainly has more 
characters than "viewer addDependent: self", but avoids the (possibly) huge 
distinction of cases in Watcher>>update:

Also, if the watcher watches several viewers, it has to query all of them if 
it only receives the CU event "update: #valueUpdate". (The viewer triggering 
the update might not be provided.) With WS events, above method could be 
modified to:

MultiWatcher>>watch: viewer
    viewer when: #valueUpdate
           send: #doSomethingWatcherSpecific
           to: self
           with: viewer

No code change in the viewer class is required to accomodate MultiWatcher :-)

> In your CU example, Alice would be an instance of Dresser and Bob will be
> an instance of Eater, where Dresser and Eater are subclasses of Person.
> Alice would wear office dress if the alarm went off in the morning or an
> evening dress if it went off in the evening.
I guess I overemphasized instance specific behavior. The situation I made up 
to show that CU events are less general probably rarely occurs in real code. I 
will incorporate your suggestion in the next version.

Cheers,
Peter