Question

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?

Answer 1

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.