On Mar 9, 2006, at 9:52 PM, Charles Yeomans wrote:
On Mar 9, 2006, at 9:07 PM, Andy Dent wrote:
On 10/03/2006, at 4:19 AM, Guyren Howe wrote:
But for those keeping score at home: no-one has offered an
example of class extension, other than the couple of corner cases
I cited, where the results are clearer/easier to write/easier to
maintain/anything else convincing, using method overriding rather
than Events.
Maybe I missed it - did someone offer such an example proving
Events are better?
<snip>
I would have to see some very good reasons for why Events are
better, to abandon the flexibility of using virtual methods
(outside of their use in Windows and controls, where they are
satisfying a different pattern).
Such reasons have been posted over and over, written about in RBD,
etc. In short, events help to avoid fragile base class problems.
To offer one example, suppose that in every REALbasic framework
class having a constructor, an Open event was added. Then we'd
never need to guess whether we should call the superclass
constructor when overriding it.
But they aren't the best device for all situations, because there
is no best device for all situations. Just to annoy Guyren, I
claim that the need to check whether an event is implemented or not
is a sign that perhaps one is better off using overriding.
Ah, see? This the kind of tone I like for a debate.
Very well. 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.
That was an example of how using Events makes your code more
maintainable. I know of no converse situation where code is more
easily maintained if you put the subclass in charge.
Furthermore, and I think more important, Events are *much* clearer:
the relationship between the superclass and the subclass is almost
perfectly self-documenting. OTOH, if you use overriding, you have to
specify which methods to override, which superclass methods to call
during the override, all that sort of thing, in a comment, or through
folklore or who knows what.
These two are some non-trivial advantages. They're not *massive*, but
they're really quite nice.
As far as I'm aware, other than two corner cases (return type
covariance, and being unable to distinguish between a return value of
0/Nil/etc from a functional event, and there being no handler), or if
you need to extend a closed-source (eg built-in) class which offers
no suitable event (which obviously doesn't apply to class hierarchies
you design), these two reasons are prima facie why you should do
essentially all class extension with Events.
I *absolutely adore* discovering that I am wrong. It means I've just
learned something important. So *please, please* describe another,
preferably common, situation where Overriding provides any
significant advantage over Events, and particularly advantages
sufficient to outweigh the above described advantages to Events.
(Sorry, Charles, but I didn't understand your last point above. Would
you expand on it?)
Guyren G Howe
guyren-at-relevantlogic.com
http://relevantlogic.com
REALbasic, PHP, Python programming
PostgreSQL, MySQL database design and consulting
Technical writing and training
_______________________________________________
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>
