On the contrary, events were not a hack. I think Andrew Barry chose
to use them instead of overriding; I suppose you could ask him.
Events are language support for the Template pattern.
Charles Yeomans
On Dec 7, 2006, at 5:40 AM, Andy Dent wrote:
On 07/12/2006, at 12:43 PM, Guyren Howe wrote:
Worth pointing out here that REALbasic has a superior mechanism:
the Event Handler. Define a method in the superclass, and call an
Event (that you define) in there. It makes the relationship
between superclass and subclass quite explicit (particularly
absent an Abstract declaration on methods), and places the
superclass in charge of the relationship rather than the subclass.
Putting the (single) superclass in charge of the relationship
rather than the (potentially many) subclasses is superior,
briefly, because you're more likely to be able to make changes in
shared behavior that aren't confounded by the when and how the
subclasses override the superclass, or when (if) the subclasses
call back to the original or other superclass support methods.
There have been numerous discussions about this on the NUG, going
back to posts by Andrew Barry (the original designer of REALbasic
and the originator of the Events paradigm) in the mid 90s, so I
won't go on at great length here.
But it deserves to be said: Events are unique to REALbasic. So if
you're reading advice about Object Oriented Programming, it won't
mention Events. Also, the REALbasic documentation is likely to
lead you to believe that Events are just for controls to propagate
user interface actions. Not so: Events are a general-purpose
extension mechanism, and except in some unusual cases, are simply
superior to method overriding.
huh?
I thought Events were a (partly) hack to get around the fact that
parent classes in the framework of RB, until 200x, didn't have
virtual methods so an alternate override mechanism was added to the
language ;-)
Maybe I've spent just too many years with other OO languages but I
really had trouble understanding this post and particularly how it
applied to a Factory situation.
I know you're a big fan of events, possibly the clearest post of
yours I have seen on the topic was
http://support.realsoftware.com/listarchives/realbasic-nug/2006-03/
msg00903.html
which I will take the liberty of quoting partly to save others
looking it up:
"I offer an example of how Events make for more easily maintained
code, and a discussion of why Events are clearer.
The example: you are creating an application with an entirely
custom user interface. All your windows are just dirty big
canvases, and you draw all your controls with custom classes.
You use method overriding. You create a MyControl class, give it
an abstract Paint method, and override this in your twenty-odd
different control subclasses, to do the actual drawing.
Now, OS X comes along, you want to do something fancier, you
decide that all your controls need a glowing backdrop and a water
drop effect. For whatever reason (this is just a hypothetical),
you need to draw the glow *before* you draw the control's details,
and the water-drop effect *after*.
You're screwed. You have to rewrite every single subclass. Each
subclass may or may not call the superclass's Paint method (they
probably didn't because it was empty), but in any event, that
doesn't give the superclass the opportunity to act both *before*
and *after* the subclass.
If you've used Events, so the superclass is calling a PaintEvent
that the subclasses use to do their stuff, you have no problem
whatever: draw the backdrop, call the event, draw the water drop
effect.
"
I do think you have a bit of a knee-jerk response to recommend
Events as a general solution and you tend to recommend them without
explaining how they are working differently.
My perspective, which may well be wrong, is:
Events reverse the normal order of polymorphism.
A parent class declares a new Event.
In the inheritance chain from that class, the HIGHEST subclass that
implements that event will have its event handler called. (For a
method, the LOWEST subclass overriding the method would be called.)
A common idiom is for a subclass that handles an event to ALSO
declare a New Event with the same name, and propagate the event
downwards by calling that event in its event handler.
This can look a bit confusing, looking like a recursive call but it
is not and if no lower class has an event handler for the new
Event, nothing will be invoked.
Events are extremely useful in the case where a superclass needs to:
a) intercept the subclass functionality
b) with the option of still calling down to that subclass (via a
New Event of the same name and calling it to "rethrow" the Event).
I suspect Event dispatching is most costly than method calls,
because rather than going to the method pointed to by a given
object, its event chain needs searching from the top down (this
could be well-optimised but I am not confident).
There is one big side-effect of your Event-based dispatching that
you don't mention, they mean the author of a subclass can never be
sure if they have completely replaced the parent class behaviour.
Overriding a method guarantees your implementation gets used
(unless a further subclass overrides it in turn). Implementing an
Event handler has no such guarantee.
As a further weakness, you have to inspect each and every class up
the inheritance hierarchy to see if they intercept the handler and
whether they rethrow the Event (just the fact that they declare a
New Event named blah is no guarantee that they also invoke it, you
have to look into their blah handler).
regards
Andy
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
