IList Interface...

I've read what MSDN has to say about this, but I'm still not sure why this is useful.  I've found it in a lot of code from my teammates and was just trying to figure out what extra this gives...here's an example of the context it was used in...

public class SomeNewClass
{
   public SomeNewClass()
{
}
}

public class SomeNewClassCollection : System.Collections.CollectionBase
{
   public SomeNewClassCollection()
{
   }

public SomeNewClass this[int index]
{
      get
      {
return (SomeNewClass)((IList)this[index]);
}
}
}

 

The description for IList is: Represents a collection of objects that can be individually accessed by index.
Now isn't the code below exactly the same since it's inheriting from CollectionBase? Isn't anything that inherits from CollectionBase already individually accessable by index?

 

public class SomeNewClass
{
public SomeNewClass()
{
}
}

public class SomeNewClassCollection : System.Collections.CollectionBase
{
   public SomeNewClassCollection()
{
   }

public SomeNewClass this[int index]
{
      get
      {
return (SomeNewClass)this[index]; // no IList Interface
}
}
}

Comments

• Anonymous
  April 06, 2005
  Well it's because CollectionBase implements various methods of the IList interface explicitly which means you have to cast to get at the IList behavior. It does this so that your custom collection's type specific methods are not cluttered up by the "generic" object based signatures.
  
  The bigger question is: Is this example valid? You should be using base.InnerList from your subclass implementation, no?
• Anonymous
  April 06, 2005
  Drew...can you give an example? A co-worker and I were trying to figure out why using InnerList would be better and couldn't see what the difference was other than InnerList being an ArrayList.
• Anonymous
  April 06, 2005
  The comment has been removed
• Anonymous
  April 06, 2005
  The code you give would be recusive: your "return (SomeNewClass)this[index]" just calls your indexer again... or am I missing something?
• Anonymous
  April 06, 2005
  I wrote:
  
  "At that point when they call IList.Add they may hand you any object reference, so you need to override OnInsert and basically do:"
  
  Obviously I meant you need to override OnValidate not OnInsert, sorry. Oh and OnValidate is called for three scenarios: IList::set_Item (the indexer), IList::Add and IList::Insert. So in all three of those you can bypass the OnValidate call as well as the OnXXX[Complete] calls if you code directly to base.InnerList.
• Anonymous
  April 06, 2005
  public SomeNewClass this[int index]
  {
  get
  {
  return (SomeNewClass)this[index]; // no IList Interface
  }
  }
  
  This will indeed create a problem. Doesn't this property look recursive with no condition to stop? So it will call (SomeNewClass)this[index] endlessly...
  
  Correct me if I'm wrong but that's what's going to happen in a method. Unless property has specific way in handling this...
• Anonymous
  April 06, 2005
  I'll try this out tomorrow when I've got some spare time. Thank you to everyone for all the discussion about this.
  
  As far now, I must do work. :)