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.Collecti ons.CollectionB ase
{
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\GUIT est\CollTest.cs (12): 'GUITest.CollTe st.Count.get' : cannot
override inherited member 'System.Collect ions.Collection Base.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]

Re: Can't override CollectionBase. Count?

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" <nospam-news@johannsen. us> wrote in message
news:mEusb.1272 8$ji1.4223@news svr25.news.prod igy.com...[color=blue]
> I have a simple object that inherits from CollectionBase and overrides the
> Count property:
>
> namespace MyTest
> {
> public class CollTest : System.Collecti ons.CollectionB ase
> {
> public override int Count
> {
> get { return 0; }
> }
> }
> }
>
> The compiler seems to think the Count method in the base class is not[/color]
marked[color=blue]
> virtual:
>
> C:\develop\GUIT est\CollTest.cs (12): 'GUITest.CollTe st.Count.get' : cannot
> override inherited member 'System.Collect ions.Collection Base.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[/color]
correct[color=blue]
> approach to use the new keyword instead? This has different symantics and
> is not preferred from our design point of view.
>
> Thanks!
>[/color]

[Eric Johannsen]

Re: Can't override CollectionBase. Count?

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" <100@100.com> wrote in message
news:OcV2A1UqDH A.3688@TK2MSFTN GP11.phx.gbl...[color=blue]
> 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[/color]
it[color=blue]
> 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" <nospam-news@johannsen. us> wrote in message
> news:mEusb.1272 8$ji1.4223@news svr25.news.prod igy.com...[color=green]
> > I have a simple object that inherits from CollectionBase and overrides[/color][/color]
the[color=blue][color=green]
> > Count property:
> >
> > namespace MyTest
> > {
> > public class CollTest : System.Collecti ons.CollectionB ase
> > {
> > public override int Count
> > {
> > get { return 0; }
> > }
> > }
> > }
> >
> > The compiler seems to think the Count method in the base class is not[/color]
> marked[color=green]
> > virtual:
> >
> > C:\develop\GUIT est\CollTest.cs (12): 'GUITest.CollTe st.Count.get' :[/color][/color]
cannot[color=blue][color=green]
> > override inherited member 'System.Collect ions.Collection Base.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[/color]
> correct[color=green]
> > approach to use the new keyword instead? This has different symantics[/color][/color]
and[color=blue][color=green]
> > is not preferred from our design point of view.
> >
> > Thanks!
> >[/color]
>
>[/color]

[100]

Re: Can't override CollectionBase. Count?

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" <nospam-news@johannsen. us> wrote in message
news:IEvsb.1281 7$NF1.6081@news svr25.news.prod igy.com...[color=blue]
> 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[/color]
class[color=blue]
> is to prevent further dirivation, and the purpose of an abstract class is[/color]
to[color=blue]
> force a base class to be derived from it before it can be used???
> Thanks,
>
> Eric
> "100" <100@100.com> wrote in message
> news:OcV2A1UqDH A.3688@TK2MSFTN GP11.phx.gbl...[color=green]
> > 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[/color][/color]
interfaces[color=blue][color=green]
> > implemented by your class and then hide the base Count property. This[/color][/color]
will[color=blue][color=green]
> > work as long as you use ICollection or IList inteface to get *Count*,[/color][/color]
but[color=blue]
> it[color=green]
> > 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" <nospam-news@johannsen. us> wrote in message
> > news:mEusb.1272 8$ji1.4223@news svr25.news.prod igy.com...[color=darkred]
> > > I have a simple object that inherits from CollectionBase and overrides[/color][/color]
> the[color=green][color=darkred]
> > > Count property:
> > >
> > > namespace MyTest
> > > {
> > > public class CollTest : System.Collecti ons.CollectionB ase
> > > {
> > > public override int Count
> > > {
> > > get { return 0; }
> > > }
> > > }
> > > }
> > >
> > > The compiler seems to think the Count method in the base class is not[/color]
> > marked[color=darkred]
> > > virtual:
> > >
> > > C:\develop\GUIT est\CollTest.cs (12): 'GUITest.CollTe st.Count.get' :[/color][/color]
> cannot[color=green][color=darkred]
> > > override inherited member[/color][/color][/color]
'System.Collect ions.Collection Base.Count.get'[color=blue][color=green][color=darkred]
> > > 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[/color]
> > correct[color=darkred]
> > > approach to use the new keyword instead? This has different symantics[/color][/color]
> and[color=green][color=darkred]
> > > is not preferred from our design point of view.
> > >
> > > Thanks!
> > >[/color]
> >
> >[/color]
>[/color]

[Eric Johannsen]

Re: Can't override CollectionBase. Count?

.... but Count is declared virtual (per my previous post):
public virtual int Count {get;}

Current MSDN link is:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/

frlrfsystemcoll ectionscollecti onbaseclasscoun ttopic.asp

.... still dazed and confused...

Eric

"100" <100@100.com> wrote in message
news:O2LnaYVqDH A.1740@TK2MSFTN GP12.phx.gbl...[color=blue]
> Hi Eric,
> No, the class is not. The Count property, though, is. Not only class can[/color]
be[color=blue]
> 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[/color]
*sealed[color=blue]
> 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" <nospam-news@johannsen. us> wrote in message
> news:IEvsb.1281 7$NF1.6081@news svr25.news.prod igy.com...[color=green]
> > 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[/color]
> class[color=green]
> > is to prevent further dirivation, and the purpose of an abstract class[/color][/color]
is[color=blue]
> to[color=green]
> > force a base class to be derived from it before it can be used???
> > Thanks,
> >
> > Eric
> > "100" <100@100.com> wrote in message
> > news:OcV2A1UqDH A.3688@TK2MSFTN GP11.phx.gbl...[color=darkred]
> > > 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[/color][/color]
> interfaces[color=green][color=darkred]
> > > implemented by your class and then hide the base Count property. This[/color][/color]
> will[color=green][color=darkred]
> > > work as long as you use ICollection or IList inteface to get *Count*,[/color][/color]
> but[color=green]
> > it[color=darkred]
> > > 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" <nospam-news@johannsen. us> wrote in message
> > > news:mEusb.1272 8$ji1.4223@news svr25.news.prod igy.com...
> > > > I have a simple object that inherits from CollectionBase and[/color][/color][/color]
overrides[color=blue][color=green]
> > the[color=darkred]
> > > > Count property:
> > > >
> > > > namespace MyTest
> > > > {
> > > > public class CollTest : System.Collecti ons.CollectionB ase
> > > > {
> > > > public override int Count
> > > > {
> > > > get { return 0; }
> > > > }
> > > > }
> > > > }
> > > >
> > > > The compiler seems to think the Count method in the base class is[/color][/color][/color]
not[color=blue][color=green][color=darkred]
> > > marked
> > > > virtual:
> > > >
> > > > C:\develop\GUIT est\CollTest.cs (12): 'GUITest.CollTe st.Count.get' :[/color]
> > cannot[color=darkred]
> > > > override inherited member[/color][/color]
> 'System.Collect ions.Collection Base.Count.get'[color=green][color=darkred]
> > > > 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[/color][/color][/color]
instance.[color=blue][color=green][color=darkred]
> > > > 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[/color][/color][/color]
symantics[color=blue][color=green]
> > and[color=darkred]
> > > > is not preferred from our design point of view.
> > > >
> > > > Thanks!
> > > >
> > >
> > >[/color]
> >[/color]
>
>[/color]

[100]

Re: Can't override CollectionBase. Count?

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" <nospam-news@johannsen. us> wrote in message
news:pCwsb.1283 0$%d2.7306@news svr25.news.prod igy.com...[color=blue]
> ... but Count is declared virtual (per my previous post):
> public virtual int Count {get;}
>
> Current MSDN link is:
>
>[/color]
http://msdn.microsoft.com/library/de...us/cpref/html/[color=blue]
> frlrfsystemcoll ectionscollecti onbaseclasscoun ttopic.asp
>
> ... still dazed and confused...
>
> Eric
>
> "100" <100@100.com> wrote in message
> news:O2LnaYVqDH A.1740@TK2MSFTN GP12.phx.gbl...[color=green]
> > Hi Eric,
> > No, the class is not. The Count property, though, is. Not only class can[/color]
> be[color=green]
> > sealed. Virtual methods and properties can be sealed as well, which[/color][/color]
means[color=blue][color=green]
> > 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[/color]
> *sealed[color=green]
> > override* modifiers if *virtual* is not set explicitly when the member[/color][/color]
is[color=blue][color=green]
> > implemented. This has happened with CollectionBase. Count.
> >
> > HTH
> > B\rgds
> > 100
> >
> > "Eric Johannsen" <nospam-news@johannsen. us> wrote in message
> > news:IEvsb.1281 7$NF1.6081@news svr25.news.prod igy.com...[color=darkred]
> > > The MSDN documentation does not indicate that CollectionBase is[/color][/color][/color]
sealed:[color=blue][color=green][color=darkred]
> > >
> > > [Serializable]
> > > public abstract class CollectionBase : IList, ICollection, IEnumerable
> > >
> > > Why would one seal an abstract class anyhow? The purpose of sealing a[/color]
> > class[color=darkred]
> > > is to prevent further dirivation, and the purpose of an abstract class[/color][/color]
> is[color=green]
> > to[color=darkred]
> > > force a base class to be derived from it before it can be used???
> > > Thanks,
> > >
> > > Eric
> > > "100" <100@100.com> wrote in message
> > > news:OcV2A1UqDH A.3688@TK2MSFTN GP11.phx.gbl...
> > > > Hi Eric,
> > > >
> > > > Maybe it is an error in the MSDN but it is not virtual. Actually it[/color][/color][/color]
is[color=blue][color=green][color=darkred]
> > > > 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[/color]
> > interfaces[color=darkred]
> > > > implemented by your class and then hide the base Count property.[/color][/color][/color]
This[color=blue][color=green]
> > will[color=darkred]
> > > > work as long as you use ICollection or IList inteface to get[/color][/color][/color]
*Count*,[color=blue][color=green]
> > but[color=darkred]
> > > 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" <nospam-news@johannsen. us> wrote in message
> > > > news:mEusb.1272 8$ji1.4223@news svr25.news.prod igy.com...
> > > > > I have a simple object that inherits from CollectionBase and[/color][/color]
> overrides[color=green][color=darkred]
> > > the
> > > > > Count property:
> > > > >
> > > > > namespace MyTest
> > > > > {
> > > > > public class CollTest : System.Collecti ons.CollectionB ase
> > > > > {
> > > > > public override int Count
> > > > > {
> > > > > get { return 0; }
> > > > > }
> > > > > }
> > > > > }
> > > > >
> > > > > The compiler seems to think the Count method in the base class is[/color][/color]
> not[color=green][color=darkred]
> > > > marked
> > > > > virtual:
> > > > >
> > > > > C:\develop\GUIT est\CollTest.cs (12): 'GUITest.CollTe st.Count.get' :
> > > cannot
> > > > > override inherited member[/color]
> > 'System.Collect ions.Collection Base.Count.get'[color=darkred]
> > > > > 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[/color][/color]
> instance.[color=green][color=darkred]
> > > > > public virtual int Count {get;}
> > > > >
> > > > > Any thoughts on why the override keyword is being rejected? Is[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > > correct
> > > > > approach to use the new keyword instead? This has different[/color][/color]
> symantics[color=green][color=darkred]
> > > and
> > > > > is not preferred from our design point of view.
> > > > >
> > > > > Thanks!
> > > > >
> > > >
> > > >
> > >[/color]
> >
> >[/color]
>[/color]