[OT] Re: An alternative FFI/Parser proposal

stéphane ducasse ducasse at iam.unibe.ch
Thu Aug 17 14:46:57 UTC 2006


yes and this is a nice idea.

PS: For the tweak fields I think that we will have to come up with a  
better idea than different color (I have friend that are daltonians
and squeakers so coloring differently the variables has no semantics  
for them).


On 17 août 06, at 10:00, Andreas Raab wrote:

> 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