Can't override CollectionBase.Count?

[Eric Johannsen]

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!

[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!

[Eric Johannsen]

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!

[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!

[Eric Johannsen]

.... 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!
>

[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!
> >
>
>