just check if the event returned a special return code which said
"yes this event is implemented".

Actually, a fairly useful Object Oriented Design heuristic is to only
make instances of your leaf classes. IOW, all non-leaf classes should
be abstract.

Employing that heuristic here removes your concerns. In this case,
you could happily have an abstract superclass, that handed down the
FSRender call in an event to two separate subclasses. The shared
functionality would go in the superclass, the differences would go in
the subclasses. The result would, to my mind, be clearer (Events
having the advantage of being much more self-documenting).

This way, all you see in code is FSRender. Like this:

for i = 0 to n
  me.Child(i).FSRender( fs )
next

No reason that an implementation using Events should not work like this.

OK, let's say I made FSRender as an event. You can't actually call events from the outside, only a class may call it's own event.

So I have "function FSRender", and "Event FSRenderEvent".

function FSRender(fs as FastString)
FSRenderEvent( fs )
end function

That basically introduces extra code, and it makes things a little bit slower. It also introduces a bit of confusion, because now I have a method wrapper for an event, and they both have a similar name.

Not *really* how I'd want to do things.

In fact I see it the other way around! Events are unnecessary! I've talked about this on the list before. An event *can* be modelled as a name-spaced method, (although that's not necessarily how RB does it).

So Lets say I have class "MySuper", and class "MySub". Both have the "GetItem" event. If I call "GetItem", the event called really depends on which class the code is in that is calling GetItem. So it's as if we actually had the method:

function MySuper_GetItem() as item... and
function MySub_GetItem() as item

This would allow for distinguishing between which "event" is called. All you'd need then is a bit of syntactic magic in the parser to imply the "MySuper_" or the "MySub_" part when coming across a call to "GetItem"!

And you'd have an event system that is built out of methods.

--
http://elfdata.com/plugin/



_______________________________________________
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>

Reply via email to