Implementing Interfaces...

Tim McCurdy

Ok, I know this might sound simple, but it's not. I want to Implement the IList interface but I want certain members of it hidden (for example IndexOf and the default public object this[int Index]) because I am creating a strongly-typed collection. In VB.NET I could easily do this because each method knew that it was Implemented by a simple: Private Function IndexOf(Value As Object) As Integer Implements IList.IndexOf. The Implementation was fine in VB like this because one could still cast the object to an IList type and access the methods on it even thought they were private within the Collection class. Does anyone know how to do this?

Christian Graus

VB lets you change the visibility of objects from an interface ? What a hack !!! Have you thought of using C# 2.0 ? It's collections are strongly typed. Otherwise, your class will need to contain an IList, not be one. Christian Graus - Microsoft MVP - C++

Tim McCurdy

Umm, no, VB does not let you change the visibility of objects from an interface. If you remember, Interfaces are SUPPOSED to be only methods WITHOUT accessors (i.e. Public, Private, etc.). So that means that any Class implementing that Interface can change the visibility to whatever they want, just as long as every method is Implemented. So, it's not a Hack, it is by design. However, I did find out how to do this in C# if anyone is interested. It's called Explicit Interface Member Implementation[^] :wtf: !!!

Matt Gerrans

It doesn't make any sense to implement an interface and then try to hide some parts of it. The whole point of the interface is to communicate what methods and properties (or more generally, behavior) your objects support. Sounds like what you should do is define your own interface that may be similar to IList, but is not, in fact IList. I know I would be more than annoyed if I was presented with an object that seemed (and claimed) to implement some interface, but then failed to correctly support all the things that the interface implied. Why would you want to do this? Matt Gerrans

Matt Gerrans

By the way, public and private are not accessors, they are "access specifiers" or "access modifiers." Matt Gerrans

J4amieC

actually you can do this in C#, I wont implement all of IList but ill show you how to make Count available publically, but IndexOf only available when typed as IList

public class MyList : IList
{
  // shows publically
  public int Count
  {
    get{return this.count; }
  }

  // notice no public or private, but only shows when instance is typed as IList
  IList.IndexOf(object obj)
  {
    return ...
  }
}

Tim McCurdy

You see, it's very simple. For someone who writes object models for a living, I've seen a lot that just don't make any sense (ex. Adobe, Maximizer, etc.). I hate when someone gives a method like "Remove" when I am working with a collection of Files (Remove what?). Instead, I like to rename the Method to "Delete" and implement the "Remove" method privately. The private method will simply call the Public method on the collection class. Don't get me wrong, I implement as much as the interface as I "can". There are some methods though that I DO like, however, the fact that you have to pass an object instead of my custom (strongly-typed) collection object (i.e. a custom File object for example). For example, if you Implement the IDictionary Interface, it uses this: IndexOf(object Key). What? Since the Keys SHOULD all be strings in my collection, why do I want to allow a programmer to pass a Guid, Int, or whatever else they can think of? If they want a guid, pass a Guid.ToString(). If you look at a lot of the pre-defined Collection classes Microsoft created, they also "hide" a lot of interface methods because they just don't make sense for the particular object, but you can still cast them to an Interface that they implement and use the Properties / Methods that way. Now, as to why I am implementing an IList? Well, It's nice to have a custom collection class that can be databound to a DataGrid or other controls.