Здравствуйте, _FRED_, Вы писали:

_FR>Что бы заинтересовать, рассуждайте шире. Рассмотрите всевозможные сценарии использования коллекций. Вы увидите, что интерфейсы для readonly-списков и коллекций попросту не нужны. Массивов и ReadOnlyCollection<> часто достаточно. ReadOnlyCollection2<> (без реализации IList/IList<>), ReadOnlySet<>, ReadOnlyDictionary<> и ковариантные классы readonly-коллекций для нового фреймворка могут покрыть все задачи. Заметье, речь тут не об интерфейсах, а о классах, которые вы можете написать самостоятельно и использовать, не имея никаких проблем с тем, что где-то видно больше, чем хотелось бы. Если у вас есть какая-то задача, которую нельзя было бы решить предложенным мною способом, было бы интересно взглянуть. Но подумайте, пожалуйста, хорошенько.

Т.е. если дистилировать весь твой пост — корявый дизайн массивов в дотнете. Так ?

Здравствуйте, Ikemefula, Вы писали:

_FR>>Что бы заинтересовать, рассуждайте шире. Рассмотрите всевозможные сценарии использования коллекций. Вы увидите, что интерфейсы для readonly-списков и коллекций попросту не нужны. Массивов и ReadOnlyCollection<> часто достаточно. ReadOnlyCollection2<> (без реализации IList/IList<>), ReadOnlySet<>, ReadOnlyDictionary<> и ковариантные классы readonly-коллекций для нового фреймворка могут покрыть все задачи. Заметье, речь тут не об интерфейсах, а о классах, которые вы можете написать самостоятельно и использовать, не имея никаких проблем с тем, что где-то видно больше, чем хотелось бы. Если у вас есть какая-то задача, которую нельзя было бы решить предложенным мною способом, было бы интересно взглянуть. Но подумайте, пожалуйста, хорошенько.

I>Т.е. если дистилировать весь твой пост — корявый дизайн массивов в дотнете. Так ?

Нет.

Здравствуйте, samius, Вы писали:

_FR>>Вот это — "пять", как говорится. То есть "неочевидная логика" в вашей логике "нелогична" И всего навсего из-за пропущенных/забытых глав из Рихтера. Потрясающая логика — рассуждать о логичности того, с чем впервые столкнулся. ИМХО, рассуждая таким путём _очень_ сложно не ошибиться.

S>Можно таки ссылку на главу у Рихтера, проливающую свет на данный вопрос?

Вечером посмотрю, сейчас нет под рукой.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, Ikemefula, Вы писали:

_FR>>>Что бы заинтересовать, рассуждайте шире. Рассмотрите всевозможные сценарии использования коллекций. Вы увидите, что интерфейсы для readonly-списков и коллекций попросту не нужны. Массивов и ReadOnlyCollection<> часто достаточно. ReadOnlyCollection2<> (без реализации IList/IList<>), ReadOnlySet<>, ReadOnlyDictionary<> и ковариантные классы readonly-коллекций для нового фреймворка могут покрыть все задачи. Заметье, речь тут не об интерфейсах, а о классах, которые вы можете написать самостоятельно и использовать, не имея никаких проблем с тем, что где-то видно больше, чем хотелось бы. Если у вас есть какая-то задача, которую нельзя было бы решить предложенным мною способом, было бы интересно взглянуть. Но подумайте, пожалуйста, хорошенько.

I>>Т.е. если дистилировать весь твой пост — корявый дизайн массивов в дотнете. Так ?

_FR>Нет.

А что значит " Вы увидите, что интерфейсы для readonly-списков и коллекций попросту не нужны."

Раз они не нужны, значит их и незачем было реализовывать, т.к. это сбивает с толку пользователей.

Здравствуйте, samius, Вы писали:

_FR>>"Что-то" ошибается. Дело в том, что IList.IsReadOnly и ICollection<>.IsReadOnly — несколько разные IsReadOnly. И это совсем не сложно. Если вы этого раньше не знали, не нужно оправдывать незнание тем, что это сложно и не нужно, а так же опасно.

S>Предлагаю указать мне на отличия в документации:
S>http://msdn.microsoft.com/en-us/library/0cfatk9t.aspx
S>http://msdn.microsoft.com/en-us/library/system.collections.ilist.isreadonly.aspx

При чём здесь документация? Мы не её обсуждаем. Но и это я покажу ниже. Потому что не смотря на моё раздражённое и, уверен, раздражающее, поведение вы более чем корректны Большое спасибо Просто очень не люблю, когда без знания дела начинают условия свои диктовать.

Напоминаю, о чём шла речь:

Что-то мне подсказывает, что IsFixedSize тут не поможет.

Так вот, логика старых интерфейсов коллекций была проста: всё, что не IList, всё readonly. А IList имеет два признака: IsFixedSize, показывающий, можно ли добавлять/удалять элементы и IsReadOnly, показывающий можно ли изменять элементы. Различия хорошо видны для массивов: для них IsFixedSize = true, а IsReadOnly = false. Это однозначно говорит о том, что мы не может добавлять/удалять элементы, но изменять сожержимое имеем право. Поэтому

Remarks

A collection that is read-only does not allow the addition, removal, or modification of elements after the collection is created.

совершенно верно: если IsReadOnly = true, нельзя добавлять/удалять/изменять, а в противном случае изменять можно (ведь другого не сказано), а по поводу добавления/удаления сказано в описании IsFixedSize.

В generic-коллекциях всё проще, там только IsReadOnly, который говорит о том [же], можно ли изменять элементы — но, так как нет уточняющего IsFixedSize, то логика его работы очень проста и для массива IList<>::IsReadOnly = true (в отличии от IList::IsReadOnly). То есть, по сути, вы не должны хоть как-то менять содержимое IList<> есть его IsReadOnly = true.

Другое дело, что реализация этого интерфейса массивом неожиданна: несмотря на IsReadOnly = true, изменять данные по индексатору она позволяет. Но, во-первых, это уже детали реализации и, во-вторых, это нигде [я не знаю где] не запрещено документацией.

Здравствуйте, Ikemefula, Вы писали:

_FR>>>>Что бы заинтересовать, рассуждайте шире. Рассмотрите всевозможные сценарии использования коллекций. Вы увидите, что интерфейсы для readonly-списков и коллекций попросту не нужны. Массивов и ReadOnlyCollection<> часто достаточно. ReadOnlyCollection2<> (без реализации IList/IList<>), ReadOnlySet<>, ReadOnlyDictionary<> и ковариантные классы readonly-коллекций для нового фреймворка могут покрыть все задачи. Заметье, речь тут не об интерфейсах, а о классах, которые вы можете написать самостоятельно и использовать, не имея никаких проблем с тем, что где-то видно больше, чем хотелось бы. Если у вас есть какая-то задача, которую нельзя было бы решить предложенным мною способом, было бы интересно взглянуть. Но подумайте, пожалуйста, хорошенько.

I>>>Т.е. если дистилировать весь твой пост — корявый дизайн массивов в дотнете. Так ?

_FR>>Нет.

I>А что значит " Вы увидите, что интерфейсы для readonly-списков и коллекций попросту не нужны."
I>Раз они не нужны, значит их и незачем было реализовывать, т.к. это сбивает с толку пользователей.

И при чём же тут "корявый дизайн массивов в дотнете"

Здравствуйте, _FRED_, Вы писали:

I>>>>Т.е. если дистилировать весь твой пост — корявый дизайн массивов в дотнете. Так ?

_FR>>>Нет.

I>>А что значит " Вы увидите, что интерфейсы для readonly-списков и коллекций попросту не нужны."
I>>Раз они не нужны, значит их и незачем было реализовывать, т.к. это сбивает с толку пользователей.

_FR>И при чём же тут "корявый дизайн массивов в дотнете"

Интерфейсы не нужны а их всунули. или по твоему реализация ненужных интерфейсов вроде IList в Array это показатель качественного дизайна ?

Здравствуйте, Ikemefula, Вы писали:

I>>>>>Т.е. если дистилировать весь твой пост — корявый дизайн массивов в дотнете. Так ?
_FR>>>>Нет.
I>>>А что значит " Вы увидите, что интерфейсы для readonly-списков и коллекций попросту не нужны."
I>>>Раз они не нужны, значит их и незачем было реализовывать, т.к. это сбивает с толку пользователей.

_FR>>И при чём же тут "корявый дизайн массивов в дотнете"

I>Интерфейсы не нужны а их всунули. или по твоему реализация ненужных интерфейсов вроде IList в Array это показатель качественного дизайна ?

Я не вижу, где и какие интерфейсы не нужны. IList/IList<> в массивах нужен. Излагайте мысли более чётко и более подробно — догадываться о т ом, что вы предполагаете я не желаю.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, samius, Вы писали:

S>>Предлагаю указать мне на отличия в документации:
S>>http://msdn.microsoft.com/en-us/library/0cfatk9t.aspx
S>>http://msdn.microsoft.com/en-us/library/system.collections.ilist.isreadonly.aspx

_FR>При чём здесь документация? Мы не её обсуждаем. Но и это я покажу ниже. Потому что не смотря на моё раздражённое и, уверен, раздражающее, поведение вы более чем корректны Большое спасибо Просто очень не люблю, когда без знания дела начинают условия свои диктовать.


_FR>Так вот, логика старых интерфейсов коллекций была проста: всё, что не IList, всё readonly.
Hashtable не вписалась в эту логику.

_FR>А IList имеет два признака: IsFixedSize, показывающий, можно ли добавлять/удалять элементы и IsReadOnly, показывающий можно ли изменять элементы. Различия хорошо видны для массивов: для них IsFixedSize = true, а IsReadOnly = false. Это однозначно говорит о том, что мы не может добавлять/удалять элементы, но изменять сожержимое имеем право. Поэтому

_FR>

_FR>A collection that is read-only does not allow the addition, removal, or modification of elements after the collection is created.

_FR>совершенно верно: если IsReadOnly = true, нельзя добавлять/удалять/изменять, а в противном случае изменять можно (ведь другого не сказано), а по поводу добавления/удаления сказано в описании IsFixedSize.
Пока со всем согласен.

_FR>В generic-коллекциях всё проще, там только IsReadOnly, который говорит о том [же], можно ли изменять элементы — но, так как нет уточняющего IsFixedSize, то логика его работы очень проста и для массива IList<>::IsReadOnly = true (в отличии от IList::IsReadOnly). То есть, по сути, вы не должны хоть как-то менять содержимое IList<> есть его IsReadOnly = true.
Ну т.е. не должен — это на моей совести?

_FR>Другое дело, что реализация этого интерфейса массивом неожиданна: несмотря на IsReadOnly = true, изменять данные по индексатору она позволяет. Но, во-первых, это уже детали реализации и, во-вторых, это нигде [я не знаю где] не запрещено документацией.
Цитата выше утверждает что у read-only коллекций запрещено изменение элементов после создания коллекци без упоминания об исключении в виде массива и его разных реализациях казалось бы одного свойства.

Надежда на Рихтера. Я во 2м издании о 2м фреймворке не нашел ничего об этом, кроме того, что generic интерфейсы коллекций поддерживаются массивами динамически (и только одномерными с индексацией от 0-я).

Здравствуйте, _FRED_, Вы писали:

_FR>Я не вижу, где и какие интерфейсы не нужны. IList/IList<> в массивах нужен. Излагайте мысли более чётко и более подробно — догадываться о т ом, что вы предполагаете я не желаю.

То нужны то не нужны, " интерфейсы для readonly-списков и коллекций попросту не нужны"

Для чего нужны IList/IList<> в массивах ?

Здравствуйте, samius, Вы писали:

_FR>>Так вот, логика старых интерфейсов коллекций была проста: всё, что не IList, всё readonly.
S>Hashtable не вписалась в эту логику.

Это отдельный разговор — там есь IDictionary со всем, что нужно.

_FR>>В generic-коллекциях всё проще, там только IsReadOnly, который говорит о том [же], можно ли изменять элементы — но, так как нет уточняющего IsFixedSize, то логика его работы очень проста и для массива IList<>::IsReadOnly = true (в отличии от IList::IsReadOnly). То есть, по сути, вы не должны хоть как-то менять содержимое IList<> есть его IsReadOnly = true.
S>Ну т.е. не должен — это на моей совести?

Что именно? Корректная реализация интерфейса? Конечно, как и при реализации любого интерфейса. От IsFixedSize отчасти из-за того и отказались, что в пользовательских коллекциях он, за исключением редчайших случаев, не нужен и равнозначен IsReadOnly.

Здравствуйте, Ikemefula, Вы писали:

_FR>>Я не вижу, где и какие интерфейсы не нужны. IList/IList<> в массивах нужен. Излагайте мысли более чётко и более подробно — догадываться о т ом, что вы предполагаете я не желаю.
I>То нужны то не нужны, " интерфейсы для readonly-списков и коллекций попросту не нужны"

У вас какая-то сумятица в голове. Процитированное означает, что не нужны IReadOnlyCollection, IReadOnlyList и прочие ридонли-интерфейсы.

I>Для чего нужны IList/IList<> в массивах ?

Например, для того, что бы можно было бы написать обобщённый метод сортировки, принимающий IList/IList<>.

Здравствуйте, samius, Вы писали:

_FR>>В generic-коллекциях всё проще, там только IsReadOnly, который говорит о том [же], можно ли изменять элементы — но, так как нет уточняющего IsFixedSize, то логика его работы очень проста и для массива IList<>::IsReadOnly = true (в отличии от IList::IsReadOnly). То есть, по сути, вы не должны хоть как-то менять содержимое IList<> есть его IsReadOnly = true.
S>Ну т.е. не должен — это на моей совести?

А, вкурил Если хотите — можете менять на свой страх и риск. Все известные мне реализации коллекций ответят на это исключением. IList<> в описанном выше случае не сделает нечего, но это какая-то его специфическая особенность.

Здравствуйте, _FRED_, Вы писали:

I>>Для чего нужны IList/IList<> в массивах ?

_FR>Например, для того, что бы можно было бы написать обобщённый метод сортировки, принимающий IList/IList<>.

Это какое то мелкое преимущество

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, samius, Вы писали:

_FR>>>В generic-коллекциях всё проще, там только IsReadOnly, который говорит о том [же], можно ли изменять элементы — но, так как нет уточняющего IsFixedSize, то логика его работы очень проста и для массива IList<>::IsReadOnly = true (в отличии от IList::IsReadOnly). То есть, по сути, вы не должны хоть как-то менять содержимое IList<> есть его IsReadOnly = true.
S>>Ну т.е. не должен — это на моей совести?

_FR>А, вкурил Если хотите — можете менять на свой страх и риск. Все известные мне реализации коллекций ответят на это исключением. IList<> в описанном выше случае не сделает нечего, но это какая-то его специфическая особенность.
По поводу какой-то специфической особенности очень хотел съязвить. Не буду
Кстати, точно так же изменение массива не приводит к облому перечислителя массива. Но это-то как раз можно понять и предугадать.

Здравствуйте, Ikemefula, Вы писали:

I>>>Для чего нужны IList/IList<> в массивах ?
_FR>>Например, для того, что бы можно было бы написать обобщённый метод сортировки, принимающий IList/IList<>.
I>Это какое то мелкое преимущество

Мне жаль, если ваша фантазия не позволяет вам отыскать других А они есть.

Здравствуйте, samius, Вы писали:

_FR>>А, вкурил Если хотите — можете менять на свой страх и риск. Все известные мне реализации коллекций ответят на это исключением. IList<> в описанном выше случае не сделает нечего, но это какая-то его специфическая особенность.
S>По поводу какой-то специфической особенности очень хотел съязвить. Не буду
S>Кстати, точно так же изменение массива не приводит к облому перечислителя массива. Но это-то как раз можно понять и предугадать.

Прежде чем об этом рассуждать, наждо поинтересоваться у разработчиков, ибо это совершенно точно шаг в сторону от общепринятых договорённостей. И осмысленный ли это шаг или просто недосмотр, ИМХО, не очевидно.

Здравствуйте, _FRED_, Вы писали:

I>>>>Для чего нужны IList/IList<> в массивах ?
_FR>>>Например, для того, что бы можно было бы написать обобщённый метод сортировки, принимающий IList/IList<>.
I>>Это какое то мелкое преимущество

_FR>Мне жаль, если ваша фантазия не позволяет вам отыскать других А они есть.

То есть примеров у тебя нет и ты решил удариться в словоблудие ?

Здравствуйте, Ikemefula, Вы писали:

I>Т.е. если дистилировать весь твой пост — корявый дизайн массивов в дотнете. Так ?

Ну вообще-то он действительно корявый

Здравствуйте, midcyber, Вы писали:

I>>Т.е. если дистилировать весь твой пост — корявый дизайн массивов в дотнете. Так ?

M>Ну вообще-то он действительно корявый

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