Массив. IsReadOnly, непоследовательный в зависимости от интерфейсной реализации

Из MSDN :

IList является потомком ICollection интерфейс и является базой интерфейс всех неуниверсальных списков. Реализации IList делятся на три категории: только для чтения, фиксированного размера и переменный размер. Доступный только для чтения список IList не может быть изменен. Список IList фиксированного размера не допускает добавления или удаления элементов, но позволяет модификация существующих элементов. А IList переменного размера позволяет добавление, удаление и изменение чья семантика поэтому отличается от неуниверсального IList.IsReadOnly. Я полагаю, что разработчики знали об этом несоответствии, но не могли вернуться и изменить семантику неуниверсального IList по причинам обратной совместимости.

Подводя итог, IList может быть:

• Variable-size.

  ] IList.IsFixedSize = false

  IList.IsReadOnly = false

  ICollection .IsReadOnly = false

• Фиксированный размер (но элементы могут быть изменены, например, массив)

  IList.IsFixedSize = true

  IList.IsReadOnly = false

  ICollection .IsReadOnly = true

• Только для чтения (элементы не могут быть изменены)

  IList.IsFixedSize = true

  IList.IsReadOnly = true

  ICollection .IsReadOnly = true

Причина такого поведения сводится к тому, что System.Array имеет 2 свойства IsReadOnly

Первое является нормальным свойством в массиве типов. Это свойство удовлетворяет свойству IsReadOnly интерфейса IList. По какой-то причине в 1.0 CLR они считали, что свойство должно возвращать true.

Второй - это явная реализация свойства для типа ICollection (фактически реализованная CLR IIRC). В этом случае IsReadOnly возвращает true, потому что тип Array не может удовлетворять изменяющим методам ICollection , таким как Add, Clear и т. Д.

Настоящий вопрос заключается в том, почему изменение между версиями? На самом деле я не знаю, но предполагаю, что авторы определили, что более уместно рассматривать массив только для чтения, когда он рассматривается как отдельная коллекция. Хотя он может удовлетворить часть изменяемых методов, он не может удовлетворить их все. Следовательно, безопаснее рассматривать его как только чтение, а не изменяемое.

На самом деле я знаю, но я предполагаю, что авторы определили, что более уместно рассматривать массив только для чтения, когда он рассматривается как отдельная коллекция. Хотя он может удовлетворить часть изменяемых методов, он не может удовлетворить их все. Следовательно, безопаснее рассматривать его как только чтение, а не изменяемое.

На самом деле я знаю, но я предполагаю, что авторы определили, что более уместно рассматривать массив только для чтения, когда он рассматривается как отдельная коллекция. Хотя он может удовлетворить часть изменяемых методов, он не может удовлетворить их все. Следовательно, безопаснее рассматривать его как только чтение, а не изменяемое.

Из документации для класса массива :

В .NET Framework версии 2.0 класс массива реализует System.Collections.Generic.IList , System.Collections.Generic.ICollection и System.Collections.Generic.IEnumerable универсальные интерфейсы. В реализации предоставляются массивам во время выполнения и поэтому не виден в сборке документации инструменты. В результате общий интерфейсы не отображаются в синтаксис объявления для массива класс, и нет ссылки темы для участников интерфейса, которые доступен только при приведении массива к общий тип интерфейса (явный реализации интерфейса). Ключ что нужно знать, когда вы бросаете массив к одному из этих интерфейсов те члены, которые добавляют, вставляют или удалить элементы throw NotSupportedException .

Итак, поскольку общие коллекции не поддерживают добавление, вставку или удаление, IsReadOnly возвращает true. Что касается того, почему он не возвращает false для System.Collections.IList ? Я предполагаю, что

var array = new int[10];
Console.WriteLine(array.IsReadOnly); // prints "True"
array[0] = 5; // WTF? This is readonly.

был не тем, что они хотели видеть. Когда они добавили универсальные интерфейсы в v2, их можно было вызывать только после того, как массив был приведен, поэтому возвращение true для них имело больше смысла.