Re: Visual Studio 2003, CollectionBase.RemoveAt Method



Okay, I get it now. First of all, there is no "normal" Collection object.
Let me explain:

Microsoft went to a great deal of trouble in making VB.Net look and act a
lot like VB6, even though it really has very little in common with VB6. This
was partially achieved by creating a NameSpace called
"Microsoft.VisualBasic," with a bunch of classes in it that look and act a
lot like VB6 Classes. One of these is the Microsoft.VisualBasic.Collection
class. You don't think of it as such because Microsoft also hid the
namespace from you. You can find it in your Project references and imports
statements.

The VB Collection class does not inherit System.Collections.CollectionBase.
Instead, like System.Collections.CollectionBase, it implements 2 interfaces,
IList and ICollection. In other words, the only thing that these 2 classes
have in common is the interfaces they implement, and the word "Collection"
in their names. Under the hood, they have completely different code.

The System.Collection.CollectionBase class has a public method called
"RemoveAt(int)" which removes an item from the Collection at the index
passed. The VB Collection does not. So, if you inherit
System.Collection.CollectionBase, it is not necessary to implement the
method; it already exists. If, on the other hand, you inherit the VB
Collection Class, you must explicitly define a "RemoveAt" method in order to
have one in your class.

So, no, there is nothing wrong with the documentation.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

"Yee Seong" <YeeSeong@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6F6AFD56-175D-4A4F-A7C3-F61AB7EFF1FC@xxxxxxxxxxxxxxxx
> Thanks! In fact there are two questions in my previous post. First, is
> about
> whether there is a wrong defination for the CollectionBase.RemoveAt method
> in
> MSDN documentation; or if it is a build mistake for the CollectionBase
> class.
> Second, is about are we able to hide the derived public method from the
> base
> class.
>
> When we compare the normal Collection object with the CollectionBase
> class,
> the RemoveAt method is not present in Collection object. I just don't
> understand why this method is declared public in the CollectionBase class,
> and make me trouble in creating my own collection class that restrict the
> deletion of item in collection.
>
> "Kevin Spencer" wrote:
>
>> I'm a bit confused, but here goes...
>>
>> First, if your class inherits CollectionBase, it already has a RemoveAt
>> method, inherited from the base class, and there is no need to override
>> it,
>> unless you want it to behave differently. You don't even have to define
>> it.
>> It is inherited. And it is public.
>>
>> Second, you can't hide anything in a derived class from a base class. The
>> base class already has no knowledge that any class is derived (inherited)
>> from it.
>>
>> And as I don't understand some of your question, I hope that information
>> is
>> sufficient to answer your question.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> ..Net Developer
>> Ambiguity has a certain quality to it.
>>
>> "Yee Seong" <YeeSeong@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:238FCF18-F14E-44A8-B0F3-5252CCA58A69@xxxxxxxxxxxxxxxx
>> >I am new to Visual Studio 2003 class programming. I went through the
>> >online
>> > help and followed the walkthrough: 'Creating Your Own Collection
>> > Class'.
>> > But
>> > I found that the definition of the RemoveAt method is different from
>> > what
>> > I
>> > found from the hints display in the Visual Studio coding editor.
>> >
>> > In either the installed or online MSDN help, the definition for
>> > RemoveAt
>> > method is show as bellow:
>> >
>> > [Visual Basic]
>> > Public Overridable Sub RemoveAt( _
>> > ByVal index As Integer _
>> > ) Implements IList.RemoveAt
>> >
>> > However from the hint display in the editor it show a different
>> > defination
>> > as:
>> > Public Overridable NotOverridabe Sub Removeat(index As Integer)?
>> >
>> > What is means by that 'Overridable NotOverridabe'? Is there something
>> > wrong
>> > in my Visual Studio 2003 installation or the .Net Framework updates
>> > installation? How can I hide this method in my derived class from the
>> > CollectionBase base class?
>> >
>> > Thanks everyone!
>>
>>
>>


.



Relevant Pages

  • Re: Visual Studio 2003, CollectionBase.RemoveAt Method
    ... RemoveAt() and Clearmethods. ... > The VB Collection class does not inherit System.Collections.CollectionBase. ... you can't hide anything in a derived class from a base class. ... >>> Microsoft MVP ...
    (microsoft.public.vsnet.general)
  • Re: Abstract Class Theory
    ... >> there would be no need for abstract methods, and no abstract classes. ... >> the derived class will be overriding, or even overloading, the base class ... > class inherit from both. ... Actually you are confusing abstract classes and interfaces. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Abstract Class Theory
    ... > the derived class will be overriding, or even overloading, the base class ... If you read into the Patterns literature, you can see that the requirement ... In addition, if you define two abstract classes, you can have a concrete ... class inherit from both. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: What the diff between a virtual method and an inheirited method
    ... To inherit a method from a base class defined as virtual is ... > to allow the derived classes to define their own unique ... functional programming, and believe me it will make you a better ...
    (comp.lang.cpp)
  • Re: Dynamic class creation at runtime
    ... dinamically a new type that inherit directly from the base class. ... I have in my assembly the base class and 2 inherited classes: ... >> classes for each single algorithm. ... >> dynamic definition of Assemblies, but I do not want to create a new Assembly, ...
    (microsoft.public.dotnet.framework.clr)

Quantcast