On Thu, 6 Mar 2003 19:33:51 -0800 (PST)
David Sankel
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