If I have an abstract class "foo" that has a public event "bar" defined
a method in this class foo publishes this event
I now have a class foo2 which inherits from foo, and a procedure which needs to be informed of the "bar" event
1) I can't define the same event in foo2. Ok, understand this
2) I can't override the event in foo2, as the event is not abstract in foo
3) Change foo:bar to be an abstract event, can now override and use in foo2, but can't use in foo, as I can't publish an abstract event
so, I am faced with the following conclusions
1) I have to define different event names in foo and foo2 (foo:bar foo2:bar2)
2) I have to subscribe foo2 to foo:bar, and in the subscriber method publish foo2:bar2 in order for the procedure to receive the event from foo
And now to my questions
A) Why can we have have overrides on methods but not properties or events
B) Why are inherited events different to methods and properties that are available to the parent class ?
C) Is there a different way to my 2 conclusions ?
I tend to follow .NET's pattern for events:
PUBLIC EVENT MyEvent (sender AS Progress.Lang.Object, e AS Consultingwerk.EventArgs)
A method in the class:
METHOD PROTECTED OnMyEvent (e AS Consultingwerk.EventArgs):
/* Eventually e validation */
THIS-OBJECT:MyEvent:Publish (THIS-OBJECT, e).
END METHOD .
I never PUBLISH the event directly. I will always execute the On... method.
Then a child class can as well call the On.... method to raise the event.
It could override the method On.... as the internal event handler as well (instead of subscribing to itself). The benefit is, that in the override you can control that your own code executes before or after everybody else's code. And you can actually cancel the event from being raised (published).
Works well for me. And obviously the whole .NET world.
Doesn't answer your question, WHY event subscription is PRIVATE and not overidable. But it's not an issue for me.
Nachricht geändert durch Mike Fechner
What I was trying to avoid was having to define the events in each
parent class that inherits from the base class, much like you can when
defining a property.
If the property is in the base class, you can reference it in the
parent, or even (with the right visibility) the procedure / class that
instantiated the parent class. You can't however, do that with events
which is a shame, as I now have to duplicate the event definition, or
use shudder an include file ...
On 18 February 2011 11:56, Mike Fechner
What I was trying to avoid was having to define the events in each parent class that inherits from the base class, much like you can when defining a property.
In the .NET pattern, the event is just defined in the shared base class.
The On... method is also in the base class.
No need to define the event more than once. The pseudo-code from my previous post was from the base class.
Overriding the method is optional. In a .NET Form, you could subscribe to it's own Shown event (defined in System.Windows.Forms.Form) - or override the OnShown method. The .NET Community considers overriding the OnShown method as being cleverer.
I must be having a blonde moment. So how does something that
instantiates the parent class subscribe to the event that is defined
in the base class ?
On 18 February 2011 12:27, Mike Fechner
So how does something that instantiates the parent class subscribe to the event that is defined in the base class ?
I'm getting a bit confused on your wording there (for many people base and parent class mean the same). I assume that the parent class inherits the base class, right.
When the event in the base class is defined PUBLIC, then it can be subscribed form any instance of classes inheriting the base class.
PUBLIC events have PUBLIC subscription. PUBLISH is always PRIVATE.
Right. Yes, I get it now
Thanks
On 18 February 2011 12:42, Mike Fechner
Yes, Mike is exactly right about how to solve the problem. I can add a little bit about the reasoning behind Publish always being PRIVATE:
Although private publish can require a little more coding in some cases, like Julian's, we did it to ensure that a developer defining an event has complete control over access to the event. The problem is that there are two aspects to events -- subscribing and publishing -- and in the most common cases, you want the two to have different access modes. To keep the syntax simple, we went with the rule that Subscribe is governed by the access modifier that appears (or is defaulted to) in the DEFINE statement, and Publish is always private. That way, you can use the "OnXxxx" approach that Mike explained and effectively give protected or even public access to the Publish, if you want. If, on the other hand, Publish were governed by the access modifier in the DEFINE statement, or if, say, it were always protected, there is no way that a developer who wants it to be private could make it private. (One alternative that we considered was to add an option to the DEFINE EVENT syntax that lets you specify the access mode for Publish separately from that for Subscribe (kind of like you can for properties). However, we decided to try to keep the syntax simple.)
-- Wayne
However, we decided to try to keep the syntax simple.)
I am very much in favor of that!
Just adding a vote that Mike has the right approach here and also a vote that parent is the superclass and child is the subclass.