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