why does the Array class implement the Ilist Interface Explicitly not Implicitly?
-
21-04-2021 - |
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?
La solution
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 theLength
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 developersIsFixedSize
: If you know you're dealing with an array, you know the size is fixedIsReadOnly
: If you know you're dealing with an array, you know it's mutableIsSynchronized
: If you know you're dealing with an array, you know it's not synchronizedItem
: The non-genericIList
interface would expose the indexers which accept/returnobject
; the specific type of array indexers are more type-safe (and again, probably supported more directly). The accessor methods inArray
provide options for arrays with a rank != 1.SyncRoot
: There's never aSyncRoot
for an arrayAdd
,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.