[OT] Re: An alternative FFI/Parser proposal

Andreas Raab andreas.raab at gmx.de
Thu Aug 17 08:00:20 UTC 2006


Brent Pinkney wrote:
> This is a bit off topic, but is there some documentation or explanation
> on why Tweak introduced the <on: > pragma to handle events.

Because it binds the event more closely to the method and allows better 
support in the tools. It is possible to use Tweak without these 
annotations, simply by using something like here:

Foo>>initialize
     self startScript: #onMumble when:{self. #mumble}.

> I am really interested in what problem it solves and why it is better than
> other alternatives.

Mostly you want to be able to put the method and its trigger in the same 
place. Why separate the two if the sole purpose is that the trigger fire 
that method. At which point you get added tool support (the events are 
displayed in the browser) additional development support (changing a 
trigger is represented live in all existing instances) and it just 
simplifies code.

> This is not a criticism at all - I really do want to know for my own didactic purposes.

For didactic purposes it may be worthwhile to consider the alternatives. 
There are two primary ones:
a) Use method with fixed names, like in Morphic. When you implement 
#mouseDown this method gets called. If you also implement 
#handlesMouseDown: that is. As if the system couldn't be smart enough to 
figure that out by itself ;-)
b) Use some wiring mechanism, like #on:send:to:. This also requires at 
least one additional method and it is not updated for instances when you 
change it.
In either case you have to go to at least two separate places to combine 
the trigger with the method. With annotations you get all the advantages 
at once:
- you only need to touch a single place
- the annotation defines the wiring to the event
- the system updates the instances accordingly

With the "extended" syntax <on: eventName in: signaler> the advantages 
are even more obvious. When you use that form the system automatically 
updates the event wiring when the value of the signaler changes. For 
example, if you were to watch the "value" field of an arbitrary object 
you might do something like here:

onTargetValueChanged
     <on: valueChanged in: target>

And as you change the "target" the method gets automatically pointed to 
the new signaler.

Cheers,
   - Andreas




More information about the Squeak-dev mailing list