4

My target language is C# with .net framework . I want to know what is the point or the reason behind this topic ?

any advice and suggestions would be highly Appreciated .

EDIT

why i asked this question ? because right now , some useful members of The Array class like index of is buring behind a cast !!! I am wondering would it be better if microsoft split the ilist interface?

siamak
  • 669
  • 1
  • 10
  • 28
  • 2
    I've changed the "c#" tag to ".net" as this isn't language-specific; it's a decision in the BCL, not at the language level. – Jon Skeet Feb 02 '12 at 07:13
  • Array.IndexOf() doesn't require a cast. If your real question is "why is it a static method" then the answer is here: http://stackoverflow.com/a/6714318/17034 – Hans Passant Feb 07 '12 at 03:30
  • first of all, I d like to say that I think calling static methods on System.Array class is ugly .anyway you can access to index of member of IList interface through any arrays by explicit casting .for example : ((IList)myArray).indexof(ourValue) . as you can see we need an explicit cast and its not very nice. – siamak Feb 11 '12 at 22:56

1 Answers1

6

It's worth noting to start with that you don't have to implement an entire interface implicitly or explicitly - it's a member-by-member decision... and I there are different reasons for different members. I'm only guessing (very few people can give a definitive answer here) but:

  • Count: I suspect that the Length property has special support when you're dealing with a specific array type (I haven't checked the IL) and is more efficient; it's cleaner not to present both to developers
  • IsFixedSize: If you know you're dealing with an array, you know the size is fixed
  • IsReadOnly: If you know you're dealing with an array, you know it's mutable
  • IsSynchronized: If you know you're dealing with an array, you know it's not synchronized
  • Item: The non-generic IList interface would expose the indexers which accept/return object; the specific type of array indexers are more type-safe (and again, probably supported more directly). The accessor methods in Array provide options for arrays with a rank != 1.
  • SyncRoot: There's never a SyncRoot for an array
  • Add, Insert, Remove, RemoveAt, Clear: You can never change an array's size, so none of these are appropriate

In other words, if you already have the compile-time information that this is an array, you already either know the answer or definitely can't use these operations - or have a better way of doing it.

The ones which could be reasonable:

  • Contains, CopyTo, IndexOf: These could all be exposed via implicit interface implementation. I don't know why they're not

GetEnumerator (from IEnumerable) is already exposed via implicit interface implementation.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • its great to see u .thanks , so as u mentioned we can say that at least , one reason is to hide some members that we dont want other users could access them such as : Add , insert, remove , and if they try to access them by using a reference to Ilist we will throw a "NotSupportedException" ,so from design perspective ,Hiding could be one purpose . am i right ? – siamak Feb 02 '12 at 07:29
  • @siamak: It's hiding for the sake of trying to *discourage* people from calling methods which will never be appropriate. – Jon Skeet Feb 02 '12 at 07:30
  • @ jon Skeet : I think The most beautiful part of your answer is _"it's a member-by-member decision.."_ . this is a very important point for developers to pay attention.thanks – siamak Feb 02 '12 at 07:45
  • 1
    I might have liked "IsReadOnly" to exist, to leave open the possibility that in future Microsoft might decide to have Array derive from ReadableArray, which would have another descendant class ImmutableArray. Code which only needs read access to an array but doesn't care if it's immutable could accept a parameter of type ReadableArray. For such a pattern to work, ReadableArray should have an "IsReadOnly" member; as a derivative of that class, Array should also. – supercat Feb 07 '12 at 16:57