On Mar 9, 2006, at 3:19 PM, Guyren Howe wrote:
On Mar 9, 2006, at 2:00 PM, Charles Yeomans wrote:
The second of these is considerably more concise than your
overriding version (although you could have replaced the entire Else
clause in your version of this with Super.HandleStartElement, and
been *almost* as concise).
Could be; the column was written based on code from one of my
projects. So in six months it will probably have been refactored to
something entirely different. I recall going back and on forth on
events v. overriding before settling on overriding.
I am usually delighted to find out I'm wrong about something. It means
I've learned something important. Someone, please delight me. :-)
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.
So for now, my assertion stands: Events are just better. You should
use Events basically for all your class extension. Until someone makes
a good case otherwise, that makes the feature request that started
this discussion not very useful or important.
Certainly I have also made the case for preferring events to overriding
when possible. But for those not blessed with a clear vision of one's
application design a priori, it's sometimes easier just to use
overriding and go back later to replace with events as the design does
become clearer. Here, such a feature request seems like a useful
thing.
But don't forget that the first lesson of "Design Patterns" is to favor
composition over inheritance :)
--------------
Charles Yeomans
_______________________________________________
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>
