[GUI] GUIs and events/callbacks.

[Nick Name]

On Thu, 6 Mar 2003 19:33:51 -0800 (PST)
David Sankel <camio@yahoo.com> wrote:

> Can someone
>  please explain, in practical terms, what the
>  advantages there are to the event method? 

I just forgot to reply to you; in my personal view, object oriented
programming, and also event-based programming, introduce the need for
too many shared/global variables to represent the stage you have reached
in a computation. Somebody calls this "decoupling"; I have always
wondered "decoupling of what from what", but this is another matter :)

For example, consider John Meacham's simple example. As G.Russel pointed
out, (almost) all the event-based implementation suffer from a problem:
if the user clicks the button twice, fastly, the program does not exit.

This is because the programs are written like

onClick button callback1

callback1 = doSomething >> unregister callback1 >> onClick button
callback2 = doSomethingElse

The first ">>" in callback1 can be the point on wich the user clicks the
button for the second time!

The correct code, with callbacks, should have been:

onClick button callback

callback = do
           lock globalState
           s <- readGlobalState
           writeGlobalState (s+1)
           unlock globalState
           case s of
                  1 -> doSomething
                  2 -> doSomethingElse

As you can imagine, if we have a time-dependent computation, the number
of branches in the "case" statement of the callbacks grows big.

In this cases, an alternative solution is to get the stream of the
clicks and then zip it with the list of action you want to perform. In
this case, you are just respecting the specification that "two
consecutive clicks will make the program exit", because you can tell
that you are catching all the clicks.

Of course there might be solutions really more clever than mine in the
callback approach. It's just one of the difficulties I found in event
driven programming, and one of the reasons I like functional programming
instead of object oriented one (if you think about it, you'll find that
things behave quite similar).

Vincenzo