469,950 Members | 1,915 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

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

Can't override CollectionBase.Count?

I have a simple object that inherits from CollectionBase and overrides the
Count property:

namespace MyTest
{
public class CollTest : System.Collections.CollectionBase
{
public override int Count
{
get { return 0; }
}
}
}

The compiler seems to think the Count method in the base class is not marked
virtual:

C:\develop\GUITest\CollTest.cs(12): 'GUITest.CollTest.Count.get' : cannot
override inherited member 'System.Collections.CollectionBase.Count.get'
because it is not marked virtual, abstract, or override

However the help in VS.Net claims otherwise:

CollectionBase.Count Property [C#]
Gets the number of elements contained in the CollectionBase instance.
public virtual int Count {get;}

Any thoughts on why the override keyword is being rejected? Is the correct
approach to use the new keyword instead? This has different symantics and
is not preferred from our design point of view.

Thanks!

Nov 15 '05 #1
5 5539
100
Hi Eric,

Maybe it is an error in the MSDN but it is not virtual. Actually it is
indeed virtual because it is implementation of ICollection interface
property, but it is *sealed* as well. Thus cannot be overriden.

What you can do is ot add ICollection interface in the list of interfaces
implemented by your class and then hide the base Count property. This will
work as long as you use ICollection or IList inteface to get *Count*, but it
won't work if you cast your object down to the base class.

class Foo: CollectionBase, ICollection
{
new public int Count
{
get{return ...;}
}
}

HTH
B\rgds
100

"Eric Johannsen" <no*********@johannsen.us> wrote in message
news:mE******************@newssvr25.news.prodigy.c om...
I have a simple object that inherits from CollectionBase and overrides the
Count property:

namespace MyTest
{
public class CollTest : System.Collections.CollectionBase
{
public override int Count
{
get { return 0; }
}
}
}

The compiler seems to think the Count method in the base class is not marked virtual:

C:\develop\GUITest\CollTest.cs(12): 'GUITest.CollTest.Count.get' : cannot
override inherited member 'System.Collections.CollectionBase.Count.get'
because it is not marked virtual, abstract, or override

However the help in VS.Net claims otherwise:

CollectionBase.Count Property [C#]
Gets the number of elements contained in the CollectionBase instance.
public virtual int Count {get;}

Any thoughts on why the override keyword is being rejected? Is the correct approach to use the new keyword instead? This has different symantics and
is not preferred from our design point of view.

Thanks!

Nov 15 '05 #2
The MSDN documentation does not indicate that CollectionBase is sealed:

[Serializable]
public abstract class CollectionBase : IList, ICollection, IEnumerable

Why would one seal an abstract class anyhow? The purpose of sealing a class
is to prevent further dirivation, and the purpose of an abstract class is to
force a base class to be derived from it before it can be used???
Thanks,

Eric
"100" <10*@100.com> wrote in message
news:Oc**************@TK2MSFTNGP11.phx.gbl...
Hi Eric,

Maybe it is an error in the MSDN but it is not virtual. Actually it is
indeed virtual because it is implementation of ICollection interface
property, but it is *sealed* as well. Thus cannot be overriden.

What you can do is ot add ICollection interface in the list of interfaces
implemented by your class and then hide the base Count property. This will
work as long as you use ICollection or IList inteface to get *Count*, but it won't work if you cast your object down to the base class.

class Foo: CollectionBase, ICollection
{
new public int Count
{
get{return ...;}
}
}

HTH
B\rgds
100

"Eric Johannsen" <no*********@johannsen.us> wrote in message
news:mE******************@newssvr25.news.prodigy.c om...
I have a simple object that inherits from CollectionBase and overrides the Count property:

namespace MyTest
{
public class CollTest : System.Collections.CollectionBase
{
public override int Count
{
get { return 0; }
}
}
}

The compiler seems to think the Count method in the base class is not

marked
virtual:

C:\develop\GUITest\CollTest.cs(12): 'GUITest.CollTest.Count.get' : cannot override inherited member 'System.Collections.CollectionBase.Count.get'
because it is not marked virtual, abstract, or override

However the help in VS.Net claims otherwise:

CollectionBase.Count Property [C#]
Gets the number of elements contained in the CollectionBase instance.
public virtual int Count {get;}

Any thoughts on why the override keyword is being rejected? Is the

correct
approach to use the new keyword instead? This has different symantics and is not preferred from our design point of view.

Thanks!



Nov 15 '05 #3
100
Hi Eric,
No, the class is not. The Count property, though, is. Not only class can be
sealed. Virtual methods and properties can be sealed as well, which means
that they cannot be overriden.
Interface members are abstract which means virtual as well. When one
implements an interface memeber one override it. C# uses implicitly *sealed
override* modifiers if *virtual* is not set explicitly when the member is
implemented. This has happened with CollectionBase.Count.

HTH
B\rgds
100

"Eric Johannsen" <no*********@johannsen.us> wrote in message
news:IE******************@newssvr25.news.prodigy.c om...
The MSDN documentation does not indicate that CollectionBase is sealed:

[Serializable]
public abstract class CollectionBase : IList, ICollection, IEnumerable

Why would one seal an abstract class anyhow? The purpose of sealing a class is to prevent further dirivation, and the purpose of an abstract class is to force a base class to be derived from it before it can be used???
Thanks,

Eric
"100" <10*@100.com> wrote in message
news:Oc**************@TK2MSFTNGP11.phx.gbl...
Hi Eric,

Maybe it is an error in the MSDN but it is not virtual. Actually it is
indeed virtual because it is implementation of ICollection interface
property, but it is *sealed* as well. Thus cannot be overriden.

What you can do is ot add ICollection interface in the list of interfaces
implemented by your class and then hide the base Count property. This will work as long as you use ICollection or IList inteface to get *Count*,
but it
won't work if you cast your object down to the base class.

class Foo: CollectionBase, ICollection
{
new public int Count
{
get{return ...;}
}
}

HTH
B\rgds
100

"Eric Johannsen" <no*********@johannsen.us> wrote in message
news:mE******************@newssvr25.news.prodigy.c om...
I have a simple object that inherits from CollectionBase and overrides

the Count property:

namespace MyTest
{
public class CollTest : System.Collections.CollectionBase
{
public override int Count
{
get { return 0; }
}
}
}

The compiler seems to think the Count method in the base class is not

marked
virtual:

C:\develop\GUITest\CollTest.cs(12): 'GUITest.CollTest.Count.get' : cannot override inherited member 'System.Collections.CollectionBase.Count.get' because it is not marked virtual, abstract, or override

However the help in VS.Net claims otherwise:

CollectionBase.Count Property [C#]
Gets the number of elements contained in the CollectionBase instance.
public virtual int Count {get;}

Any thoughts on why the override keyword is being rejected? Is the

correct
approach to use the new keyword instead? This has different symantics and is not preferred from our design point of view.

Thanks!


Nov 15 '05 #4
.... but Count is declared virtual (per my previous post):
public virtual int Count {get;}

Current MSDN link is:

http://msdn.microsoft.com/library/de...us/cpref/html/
frlrfsystemcollectionscollectionbaseclasscounttopi c.asp

.... still dazed and confused...

Eric

"100" <10*@100.com> wrote in message
news:O2**************@TK2MSFTNGP12.phx.gbl...
Hi Eric,
No, the class is not. The Count property, though, is. Not only class can be sealed. Virtual methods and properties can be sealed as well, which means
that they cannot be overriden.
Interface members are abstract which means virtual as well. When one
implements an interface memeber one override it. C# uses implicitly *sealed override* modifiers if *virtual* is not set explicitly when the member is
implemented. This has happened with CollectionBase.Count.

HTH
B\rgds
100

"Eric Johannsen" <no*********@johannsen.us> wrote in message
news:IE******************@newssvr25.news.prodigy.c om...
The MSDN documentation does not indicate that CollectionBase is sealed:

[Serializable]
public abstract class CollectionBase : IList, ICollection, IEnumerable

Why would one seal an abstract class anyhow? The purpose of sealing a class
is to prevent further dirivation, and the purpose of an abstract class is to
force a base class to be derived from it before it can be used???
Thanks,

Eric
"100" <10*@100.com> wrote in message
news:Oc**************@TK2MSFTNGP11.phx.gbl...
Hi Eric,

Maybe it is an error in the MSDN but it is not virtual. Actually it is
indeed virtual because it is implementation of ICollection interface
property, but it is *sealed* as well. Thus cannot be overriden.

What you can do is ot add ICollection interface in the list of interfaces implemented by your class and then hide the base Count property. This will work as long as you use ICollection or IList inteface to get *Count*, but
it
won't work if you cast your object down to the base class.

class Foo: CollectionBase, ICollection
{
new public int Count
{
get{return ...;}
}
}

HTH
B\rgds
100

"Eric Johannsen" <no*********@johannsen.us> wrote in message
news:mE******************@newssvr25.news.prodigy.c om...
> I have a simple object that inherits from CollectionBase and overrides the
> Count property:
>
> namespace MyTest
> {
> public class CollTest : System.Collections.CollectionBase
> {
> public override int Count
> {
> get { return 0; }
> }
> }
> }
>
> The compiler seems to think the Count method in the base class is
not marked
> virtual:
>
> C:\develop\GUITest\CollTest.cs(12): 'GUITest.CollTest.Count.get' :

cannot
> override inherited member

'System.Collections.CollectionBase.Count.get' > because it is not marked virtual, abstract, or override
>
> However the help in VS.Net claims otherwise:
>
> CollectionBase.Count Property [C#]
> Gets the number of elements contained in the CollectionBase instance. > public virtual int Count {get;}
>
> Any thoughts on why the override keyword is being rejected? Is the
correct
> approach to use the new keyword instead? This has different

symantics and
> is not preferred from our design point of view.
>
> Thanks!
>



Nov 15 '05 #5
100
Eric,
How I said it is an error in MSDN. I don't know how to call it as long as we
can see in mscorlib.dll that CollectionBase.Count is sealed as well as
*Clear* method. The same goes for DictionaryBase. I think the doc generator
they use doesn't catch correctly those cases with interface implementation.
Anyway, this is not the only place in MSDN where you can find incorrect or
even wrong inforamation.

B\rgds
100

"Eric Johannsen" <no*********@johannsen.us> wrote in message
news:pC******************@newssvr25.news.prodigy.c om...
... but Count is declared virtual (per my previous post):
public virtual int Count {get;}

Current MSDN link is:

http://msdn.microsoft.com/library/de...us/cpref/html/ frlrfsystemcollectionscollectionbaseclasscounttopi c.asp

... still dazed and confused...

Eric

"100" <10*@100.com> wrote in message
news:O2**************@TK2MSFTNGP12.phx.gbl...
Hi Eric,
No, the class is not. The Count property, though, is. Not only class can

be
sealed. Virtual methods and properties can be sealed as well, which means
that they cannot be overriden.
Interface members are abstract which means virtual as well. When one
implements an interface memeber one override it. C# uses implicitly

*sealed
override* modifiers if *virtual* is not set explicitly when the member is implemented. This has happened with CollectionBase.Count.

HTH
B\rgds
100

"Eric Johannsen" <no*********@johannsen.us> wrote in message
news:IE******************@newssvr25.news.prodigy.c om...
The MSDN documentation does not indicate that CollectionBase is sealed:
[Serializable]
public abstract class CollectionBase : IList, ICollection, IEnumerable

Why would one seal an abstract class anyhow? The purpose of sealing a

class
is to prevent further dirivation, and the purpose of an abstract class is
to
force a base class to be derived from it before it can be used???
Thanks,

Eric
"100" <10*@100.com> wrote in message
news:Oc**************@TK2MSFTNGP11.phx.gbl...
> Hi Eric,
>
> Maybe it is an error in the MSDN but it is not virtual. Actually it is > indeed virtual because it is implementation of ICollection interface
> property, but it is *sealed* as well. Thus cannot be overriden.
>
> What you can do is ot add ICollection interface in the list of

interfaces
> implemented by your class and then hide the base Count property. This will
> work as long as you use ICollection or IList inteface to get
*Count*, but
it
> won't work if you cast your object down to the base class.
>
> class Foo: CollectionBase, ICollection
> {
> new public int Count
> {
> get{return ...;}
> }
> }
>
> HTH
> B\rgds
> 100
>
> "Eric Johannsen" <no*********@johannsen.us> wrote in message
> news:mE******************@newssvr25.news.prodigy.c om...
> > I have a simple object that inherits from CollectionBase and

overrides the
> > Count property:
> >
> > namespace MyTest
> > {
> > public class CollTest : System.Collections.CollectionBase
> > {
> > public override int Count
> > {
> > get { return 0; }
> > }
> > }
> > }
> >
> > The compiler seems to think the Count method in the base class is not > marked
> > virtual:
> >
> > C:\develop\GUITest\CollTest.cs(12): 'GUITest.CollTest.Count.get' :
cannot
> > override inherited member

'System.Collections.CollectionBase.Count.get'
> > because it is not marked virtual, abstract, or override
> >
> > However the help in VS.Net claims otherwise:
> >
> > CollectionBase.Count Property [C#]
> > Gets the number of elements contained in the CollectionBase instance. > > public virtual int Count {get;}
> >
> > Any thoughts on why the override keyword is being rejected? Is
the > correct
> > approach to use the new keyword instead? This has different

symantics and
> > is not preferred from our design point of view.
> >
> > Thanks!
> >
>
>


Nov 15 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by Thomas Kehl | last post: by
5 posts views Thread by Hoang Do | last post: by
3 posts views Thread by Poewood | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.