Overriding properties and events

  • Thread starter Thread starter Edward Diener
  • Start date Start date
E

Edward Diener

Is it possible for a derived class to override a property and/or event of
its base class ?
 
Only if the base class has that item marked as overrideable. If not, you'll
need to use Shadows.
 
Scott said:
Only if the base class has that item marked as overrideable. If not,
you'll need to use Shadows.
Click to expand...

I assume when you say Shadows you mean that the derived class creates a
property or event with the same name as the base class and calls down to the
base class as needed.

What in the documentation tells me if the item is marked as overrideable ?
If I look at the MSDN documentation for the .NET framework and I see a
property for a class, I see no mention of overrideable in any language
example for get or set functions. Can you point me to a property in the
documentation which shows this ?

As far as events are concerned, I was thinking of the ability to override
the adding, removing, and/or raising of an event. Yet documentation for an
event tells me nothing about these individual event functions for a given
event but just about the event itself. For my own events I make them virtual
in C++ and, I believe, all functions are virtual in C#. Can I override the
add_XXX, remove_XXX, or raise_XXX for a public event ? What abouyt for a
protected event ?
 
Edward Diener said:
I assume when you say Shadows you mean that the derived class creates a
property or event with the same name as the base class and calls down to
the
base class as needed.
Click to expand...
Yes, Shadows is a VB term. Its called a "new" member in C# and I dunno about
C++, though I'm sure you do. I believe Shadows may actually remove all
overloads with the same name, but I'm not sure.
What in the documentation tells me if the item is marked as overrideable ?
If I look at the MSDN documentation for the .NET framework and I see a
property for a class, I see no mention of overrideable in any language
example for get or set functions. Can you point me to a property in the
documentation which shows this ?
Click to expand...
For C# and C++, the declaration should be marked virtual or abstract, while
the VB version will be marked overridable or MustInherit(I think). Again,
overridable and MustIherit are vb specific terms.
As far as events are concerned, I was thinking of the ability to override
the adding, removing, and/or raising of an event. Yet documentation for an
event tells me nothing about these individual event functions for a given
event but just about the event itself. For my own events I make them
virtual
in C++ and, I believe, all functions are virtual in C#. Can I override the
add_XXX, remove_XXX, or raise_XXX for a public event ? What abouyt for a
protected event ?
Click to expand...

You should be able to override them for *virtual* events. Well, only add_XXX
and remove_XXX directly in C#, just as you would a property. I believe C#
requires that you override both add and remove if you override either, but
it does not support raise operators per se, instead you will simply see a
raise_XXX method. So the runtime will support it entirely, its all a matter
of what your language allows. You may wanna post to the MC++ group for
specific syntax and restrictions that C++ places on event overriding(I put
example C# code at the bottom, unfortunatly I'm not familiar enough with C++
to give you an example).

In practice, virtual events seem pretty rare, made rarer by the lack of
raise support in C# I think. Its a pity its missing, especially since C++
and apparently VB in the near future will support them.


public class A
{
public virtual event EventHandler Test;
}

public class B : A
{
EventHandler handler;
public override event EventHandler Test
{
add
{
handler = (EventHandler)Delegate.Combine(handler,value);
}

remove
{
handler = (EventHandler)Delegate.Remove(handler,value);
}
}

}
 
Edward Diener said:
I assume when you say Shadows you mean that the derived class creates a
property or event with the same name as the base class and calls down to
the
base class as needed.

What in the documentation tells me if the item is marked as overrideable ?
If I look at the MSDN documentation for the .NET framework and I see a
property for a class, I see no mention of overrideable in any language
example for get or set functions. Can you point me to a property in the
documentation which shows this ?
Click to expand...
Forgot:
http://msdn.microsoft.com/library/d...rfsystemwindowsformscontrolclasstexttopic.asp

Read the declarations, note virtual, __virtual, and overridable
 
Daniel said:
Yes, Shadows is a VB term. Its called a "new" member in C# and I
dunno about C++, though I'm sure you do. I believe Shadows may
actually remove all overloads with the same name, but I'm not sure.

For C# and C++, the declaration should be marked virtual or abstract,
while the VB version will be marked overridable or MustInherit(I
think). Again, overridable and MustIherit are vb specific terms.
Click to expand...

I do see this in the documentation, after you have pointed it out to me for
Text.Control. What is amusing is that the VB and C# doc syntax example will
have the appropriate syntax for telling me that the property is
overrideable, while the C++ does not, for many properties. However this just
tells me that the doc is wrong since if a property is overrideable in the
other languages it has to be virtual in C++ also. After all, .NET components
are usable from all .NET languages in the same general way.
You should be able to override them for *virtual* events. Well, only
add_XXX and remove_XXX directly in C#, just as you would a property.
I believe C# requires that you override both add and remove if you
override either, but it does not support raise operators per se,
instead you will simply see a raise_XXX method. So the runtime will
support it entirely, its all a matter of what your language allows.
You may wanna post to the MC++ group for specific syntax and
restrictions that C++ places on event overriding(I put example C#
code at the bottom, unfortunatly I'm not familiar enough with C++ to
give you an example).

In practice, virtual events seem pretty rare, made rarer by the lack
of raise support in C# I think. Its a pity its missing, especially
since C++ and apparently VB in the near future will support them.
Click to expand...

I agree with you that there should be more virtual events. I would even go
so far as to say that nearly all properties and events should be
overrideable in derived classes. When I develop components, I almost always
make all properties and events overrideable. I do not see the overhead of
this as being that great anymore on modern OSs and frameworks. Of course if
I did not want a derived class to override a property or event, because its
operation is too specific to my class itself, I would not make it
overrideable. But that is a very rare case.

In C++ the raise_XXX method is overrideable if it is declared virtual.
Normally for public events automatically generated, the add_XXX and
remove_XXX are generated as public and the raise_XXX is generated as
protected. If the event is virtual, then all of them are overrideable by a
derived class in C++.

Overriding events, and properties also, should be given more information in
the .NET docs, and every language should have the abilities to override
properties and events just as they would override methods. This gives the
component developer maximum flexibility in creating new classes from the
ones in the .NET framework. The documentation does not really address this
issue of overriding properites and events very well, but it should.
 
Edward Diener said:
I do see this in the documentation, after you have pointed it out to me
for
Text.Control. What is amusing is that the VB and C# doc syntax example
will
have the appropriate syntax for telling me that the property is
overrideable, while the C++ does not, for many properties. However this
just
tells me that the doc is wrong since if a property is overrideable in the
other languages it has to be virtual in C++ also. After all, .NET
components
are usable from all .NET languages in the same general way.


I agree with you that there should be more virtual events. I would even go
so far as to say that nearly all properties and events should be
overrideable in derived classes. When I develop components, I almost
always
make all properties and events overrideable. I do not see the overhead of
this as being that great anymore on modern OSs and frameworks. Of course
if
I did not want a derived class to override a property or event, because
its
operation is too specific to my class itself, I would not make it
overrideable. But that is a very rare case.
Click to expand...

The biggest issue is that, since C# does not support raise_, there is no
enforcement and providing virtual events to a C# user who derives from them
is basically begging for the user to break your component. Since the
framework shy's away from raise accessors, most C# developers aren't even
aware they can exist and very well may not have the sense to override
raise_MyEvent to have it raise the event they just changed. I think its a
bit too risky to do in any component that will be released into the wild,
atleast without *very* strong documentation and following the OnXxx pattern
exposed in windows forms.

Also, when you override a property or event, I believe the compiler emits
new metadata for that property as well as overriding the methods. By doing
this, a language that doesn't recognize raise may not include the raise
method(or others) in its redefinition and result in some nasty situations
where a class written in C++ is inherited in C#, and then that class is
inherited by another written in C++, and the event no longer has a raise
method associated.(Note that, since I havn't tested, C# and C++ should not
be taken as absolutes. Unless there is a spec section dealing with this,
this could be any pair of languages)
Unfortunatly, I can't test that right now since I do not have MC++
installed, I would be curious to see if there are any issues with this. I do
not recall a section in the spec that defines this behaviour....I'll look
into it. Hopefully there is definition, but it seems like something obscure
enough that you might want to be atleast aware of the possiblity.
 
No, Shadowed members replace the implementation of the base class member.
The difference between Shadows and Overrides is that to Override, you need
permission from the base class (the base class member must be declared as
Overrideable). With Shadows, you do not need "permission" from the base
class.
 
Back
Top