On Sat, 12 May 2001, Jim Benson wrote:

> Scott,
>
> >This may be an artifact of Squeak not having block closures;
> > they're really critical for this type of event-handling system...
> >
>
> You're kidding right?
>

No..

Basically, using block closures seems a good choice here...

My judgement (note I don't know morphic) was I didn't think that it made
sense to subclass an object for EACH individual button that was pressed,
just to overload the pushButton method for the slightly different
functionality of this button. Java 1.0 had this flaw... Too much insane
subclassing. And it was driving people nuts.. Why should each button
require a seperate class?

I got indications that Morphic handles events for buttons and such by
having the user of the button pass it a target, a selector symbol and an
argument?
  SimpleButtonMorph>>doButtonAction seems to use show that this is what
you use. This seems close to the Java 1.2 event model: Either you create a
small anonymous class to store the event handler, or they have such a
'generic' class that uses reflection to invoke a named method of your
choice.. Exactly as morphic does?



But, this mechanism seems less powerful than just using closures.

Something which is basically identical to the current scheme like:

*
  foo addEventHandler: (PushButton getButtonPushEvent)
                   do: [ event |
                           SomeTarget SomeSelector: Somearguments ]
*

Using something based around closures would seem to be clearer and be a
much larger superset of the this functionality. Among other things, no
explicit maintance or creation of the argument array for the methods being
invoked. The closure-generator automatically closes over the state thats
used by the event handler.

This depends on the existance of closures though. Which squeak doesn't yet
have?


--

Anyways, while closures aren't necessary, they sure are a lot more
syntatically cleaner way of doing this type of system compared to the
other two alternatives. Relatively short, simple, elegant.

TCL does not have closures, but they do have a construction
that does enough that lets them use the last technique:
   button $frame.$i -text "Hello" -command "do:button:$i $fr 12"
IE: it does partial expansion of the "" to automatically embed the
arguments... its automatic, and syntatically clean.


Thus, I was curious if there was any other reason to use the current
method-based mechanism instead of a closure-based one, other than the lack
of closures..


I come from a very strong LISP/SML background. I really really like
closures. :)

I'll kiss the feet of the person who brings them to Squeak.. (Any verdict
on how long it'll be?)


Scott

--

Off Topic:

>
> Uh, no movie company or record company I have worked for creates
> knowledge for the public domain. They mostly spend their own money to
> record audio and films for entertainment purposes. I'm pretty sure
> that's why they copyright the material, but I may be mistaken.
>

The purpose of copyright is to ``further the useful arts and sciences'' I
don't see how this is furthered by the fact that DVD's, like 40 year old
film, will molder away and be destroyed before those who care will ever be
able to store and archive them.

--
No DVD movie will ever enter the public domain, nor will any CD. The last CD
and the last DVD will have moldered away decades before they leave copyright.
This is not encouraging the creation of knowledge in the public domain.