470,588 Members | 2,126 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,588 developers. It's quick & easy.

Problem to override a Property

Hello.
I provided a class, which derives from the class DataView.
The only thing, which I would like to do in this class am to overwrite the
Property COUNT.
I wars it however simply not. I get always following message from the
compiler, although COUNT of the DataView (according to MSDN) is virtual.
the element ' System.Data.DataView.Count.get ' cannot be overwritten,
because as virtually, abstract or do not overwrite it is marked
Can someone help me?
Thanks Thomas
Nov 15 '05 #1
7 1933
Thomas Kehl <t.****@heeb.com> wrote:
I provided a class, which derives from the class DataView.
The only thing, which I would like to do in this class am to overwrite the
Property COUNT.
I wars it however simply not. I get always following message from the
compiler, although COUNT of the DataView (according to MSDN) is virtual.


I believe this is a bug in the documentation. If you look at the type
with ILDASM or Reflector, you'll see it's not actually virtual.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #2
Hi Jon,
when I look into System.Data with the Objectbrowser, I see, that the
definition of the Property is the fallowing:

public virtual new int Count [ get]

I think, I should be able to override it, should'nt I?

regards
thomas
"Jon Skeet" <sk***@pobox.com> schrieb im Newsbeitrag
news:MP************************@news.microsoft.com ...
Thomas Kehl <t.****@heeb.com> wrote:
I provided a class, which derives from the class DataView.
The only thing, which I would like to do in this class am to overwrite the Property COUNT.
I wars it however simply not. I get always following message from the
compiler, although COUNT of the DataView (according to MSDN) is virtual.


I believe this is a bug in the documentation. If you look at the type
with ILDASM or Reflector, you'll see it's not actually virtual.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #3
Thomas Kehl <t.****@heeb.com> wrote:
when I look into System.Data with the Objectbrowser, I see, that the
definition of the Property is the fallowing:

public virtual new int Count [ get]

I think, I should be able to override it, should'nt I?


I think it's taking that from the documentation rather than from the
assembly itself - it's certainly *not* virtual. The IL in ILDASM shows

..method public hidebysig newslot specialname virtual final
instance int32 get_Count() cil managed

and although "virtual" appears there, so does "final". It's all a bit
confusing, but I'm sure the upshot is that it's not virtual, I'm afraid
:(

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #4
The short answer is that MSDN and the object browser are wrong: the
property is not virtual.

The longer answer is that the DataView.Count property is non-virtual, and
is part of the implementation of the IComponent interface
(IComponent.Count). C# allows non-virtual interface implemenations, but
the CLR requires that all methods which implement interfaces be virtual.
So the compiler emits this in metadata as "newslot virtual final." So it
has the virtual flag set in metadata, but is final so that you cannot
override it.

-Mark
--
Mark Andersen, Visual C# Team
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
--------------------
From: Jon Skeet <sk***@pobox.com>
Subject: Re: Problem to override a Property
Date: Thu, 25 Sep 2003 19:28:25 +0100
Message-ID: <MP************************@news.microsoft.com>
References: <ud**************@TK2MSFTNGP11.phx.gbl> <MP************************@news.microsoft.com>
<OR**************@TK2MSFTNGP11.phx.gbl>MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Newsreader: MicroPlanet Gravity v2.60
Newsgroups: microsoft.public.dotnet.languages.csharp
NNTP-Posting-Host: cpc3-rdng5-6-0-cust143.winn.cable.ntl.com 81.103.154.143
Lines: 1
Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP10.phx.gbl
Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.csharp:187372
X-Tomcat-NG: microsoft.public.dotnet.languages.csharp

Thomas Kehl <t.****@heeb.com> wrote:
when I look into System.Data with the Objectbrowser, I see, that the
definition of the Property is the fallowing:

public virtual new int Count [ get]

I think, I should be able to override it, should'nt I?


I think it's taking that from the documentation rather than from the
assembly itself - it's certainly *not* virtual. The IL in ILDASM shows

.method public hidebysig newslot specialname virtual final
instance int32 get_Count() cil managed

and although "virtual" appears there, so does "final". It's all a bit
confusing, but I'm sure the upshot is that it's not virtual, I'm afraid
:(

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too


Nov 15 '05 #5

"Mark Andersen [MSFT]" <ma****@online.microsoft.com> wrote in message
news:7k**************@cpmsftngxa06.phx.gbl...
The short answer is that MSDN and the object browser are wrong: the
property is not virtual.

The longer answer is that the DataView.Count property is non-virtual, and
is part of the implementation of the IComponent interface
(IComponent.Count). C# allows non-virtual interface implemenations, but
the CLR requires that all methods which implement interfaces be virtual.
So the compiler emits this in metadata as "newslot virtual final." So it
has the virtual flag set in metadata, but is final so that you cannot
override it.


So C# does not allow a method to be declared "virtual sealed", but will
generate the equivalent in IL for methods that are not declared virtual.
Interesting :-)
Nov 15 '05 #6
Mike Schilling <ms*************@hotmail.com> wrote:
So C# does not allow a method to be declared "virtual sealed", but will
generate the equivalent in IL for methods that are not declared virtual.
Interesting :-)


Yes - as far as I can see, the CLR itself has some very odd terminology
in terms of "virtual" - it requires a method to be "virtual" to end up
being the resolution of a virtual call, even if it's not virtual in the
sense of being overridable (which is the sense the C# specification
uses). I don't think it's helping the discussion on what virtual means
:(

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #7

"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Mike Schilling <ms*************@hotmail.com> wrote:
So C# does not allow a method to be declared "virtual sealed", but will
generate the equivalent in IL for methods that are not declared virtual.
Interesting :-)


Yes - as far as I can see, the CLR itself has some very odd terminology
in terms of "virtual" - it requires a method to be "virtual" to end up
being the resolution of a virtual call, even if it's not virtual in the
sense of being overridable (which is the sense the C# specification
uses). I don't think it's helping the discussion on what virtual means
:(


If I had to guess (and I do, since I'm too lazy to look it up :-), I'd
suspect that to the CLR "virtual" means "occupies a slot in the virtual
function table". The fact that the only difference between "virtual" and
"override" methods in C# is that the former generates the "newslot" CLR
keyword encourages me in this belief.
Nov 15 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Omer van Kloeten | last post: by
5 posts views Thread by jorfei | last post: by
1 post views Thread by SpookyET | last post: by
reply views Thread by Jongmin | last post: by
reply views Thread by Kristopher Wragg | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.