Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, samius, Вы писали:
S>>Кстати, точно так же изменение массива не приводит к облому перечислителя массива. Но это-то как раз можно понять и предугадать.
_FR>Прежде чем об этом рассуждать, наждо поинтересоваться у разработчиков, ибо это совершенно точно шаг в сторону от общепринятых договорённостей. И осмысленный ли это шаг или просто недосмотр, ИМХО, не очевидно.
Как раз все просто. Либо общепринятая договоренность, либо возможность обращаться к элементам массива через ссылки Swap(ref array[0], ref array[1]);
При изменении элементов массива через ссылки нет возможности соблюдать договоренность об обломе перечислителя. Так зачем делать разницу между изменением элемента массива через сеттер индексатора и напрямую? Ну а раз так, то и реализация сеттера индексатора IList<T> оказалась с нарушением договоренности. Хотя в последнем случае как раз была возможность ее соблюсти.
Здравствуйте, Ikemefula, Вы писали:
I>>>>>Для чего нужны IList/IList<> в массивах ? _FR>>>>Например, для того, что бы можно было бы написать обобщённый метод сортировки, принимающий IList/IList<>. I>>>Это какое то мелкое преимущество _FR>>Мне жаль, если ваша фантазия не позволяет вам отыскать других А они есть.
I>То есть примеров у тебя нет и ты решил удариться в словоблудие ?
Почему же? Если я сказал, что есть, значит есть. Доказать обратного вы не сможете же, так что словоблудием занимаетесь сами.
В качестве ещё одлного примера — из массива можно создать ReadOnlyCollection<>. Например, это позволит обойти странный феномен возможности изменения через индексер данных массива несмотря на IsReadOnly.
Так что дело по прежнему в работе вашей фантазии.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Ikemefula, Вы писали:
I>>>Это какое то мелкое преимущество
_FR>>Мне жаль, если ваша фантазия не позволяет вам отыскать других А они есть.
I>То есть примеров у тебя нет и ты решил удариться в словоблудие ?
Это обычный прием, чему ты удивляешься? Раз собеседник начинает переходить на личности, то аргументы закончились. Сам так регулярно делаю, иногда даже срабатывает.
Здравствуйте, Lloyd, Вы писали:
I>>То есть примеров у тебя нет и ты решил удариться в словоблудие ?
L>Это обычный прием, чему ты удивляешься? Раз собеседник начинает переходить на личности, то аргументы закончились. Сам так регулярно делаю, иногда даже срабатывает.
Мне нужно было таки выдавить из него ответ и я применил точно такой же приём
Здравствуйте, _FRED_, Вы писали:
I>>То есть примеров у тебя нет и ты решил удариться в словоблудие ?
_FR>Почему же? Если я сказал, что есть, значит есть. Доказать обратного вы не сможете же, так что словоблудием занимаетесь сами.
Вообще то каждый доказывает ровно то что говорит.
"Доказать обратного" — это конспироложество вроде "Бог есть или докажите обратное".
Ты сказал, что есть преимущества, на вопрос не ответил кроме как сортировкой
_FR>В качестве ещё одлного примера — из массива можно создать ReadOnlyCollection<>. Например, это позволит обойти странный феномен возможности изменения через индексер данных массива несмотря на IsReadOnly.
Можно подумать, если бы массив не реализовывал был интерфейсы, были бы какие то проблемы.
Всего лишь дизайн изменяется.
Смотри:
Предположим, массив не реализует никаких интерфейсво вроде ICollection или IList и тд.
Задача — из массива сделать ReadOnlyCollection<>.
Решение — создать конструктор ReadOnlyCollection который принимает Array.
Побочный эффект — IList и тд не является Array.
Устранение побочного эффекта — в интерфейсы вроде ICollection, IList добавить фунцыю ToArray() вместо дерьма вроде CopyTo()
Здравствуйте, Ikemefula, Вы писали:
I>Можно подумать, если бы массив не реализовывал был интерфейсы, были бы какие то проблемы. I>Всего лишь дизайн изменяется. I>Смотри: I>Предположим, массив не реализует никаких интерфейсво вроде ICollection или IList и тд. I>Задача — из массива сделать ReadOnlyCollection<>. I>Решение — создать конструктор ReadOnlyCollection который принимает Array. I>Побочный эффект — IList и тд не является Array. I>Устранение побочного эффекта — в интерфейсы вроде ICollection, IList добавить фунцыю ToArray() вместо дерьма вроде CopyTo()
Нет уж, сказали — покажите. Пока что я вижу возможность такого либо специализированной под массив, то есть отдельной, реализиции, либо копированием массива в список. И то и другое по сравнению с тем, что есть, выглядит намного хуже. Так как — сумеете ответить за свои слова и прести реализацию ReadOnlyCollection<>, поддерживающую как IList<> так и массив или не сумеете?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Нет уж, сказали — покажите. Пока что я вижу возможность такого либо специализированной под массив, то есть отдельной, реализиции, либо копированием массива в список. И то и другое по сравнению с тем, что есть, выглядит намного хуже. Так как — сумеете ответить за свои слова и прести реализацию ReadOnlyCollection<>, поддерживающую как IList<> так и массив или не сумеете?
IList<> в ReadOnlyCollection есть зло !
В прынцыпе, в массиве IEnumerable можно оставить, шоб вообще всё было сильно
interface IEnumerable<T> : IEnumerable
{
...
}
class Array<T> : IEnumerable<T>
{
...
}
interface IReadonlyCollection<T> : IEnumerable<T>
{
...
T[] ToArray(); // заместо CopyTo
...
}
interface ICollection<T> : IReadonlyCollection<T>
{
...
}
interface IList<T> : ICollection<T>
{
...
...
}
class ReadOnlyCollection<T> : IReadonlyCollection<T> // и никаких IList
{
T[] _items;
...
public ReadOnlyCollection(IEnumerable<T> items)
{
// нынешняя ReadonlyCollection этого не делает и приходится вызывать Enumerable.ToList() самому или следить за геморроем
Copy(items);
}
...
}
Здравствуйте, Ikemefula, Вы писали:
_FR>>Нет уж, сказали — покажите. Пока что я вижу возможность такого либо специализированной под массив, то есть отдельной, реализиции, либо копированием массива в список. И то и другое по сравнению с тем, что есть, выглядит намного хуже. Так как — сумеете ответить за свои слова и прести реализацию ReadOnlyCollection<>, поддерживающую как IList<> так и массив или не сумеете?
I>IList<> в ReadOnlyCollection есть зло !
I>В прынцыпе, в массиве IEnumerable можно оставить, шоб вообще всё было сильно
Спасибо, но ваш пример убедительно показывает вашу некомпетентность в обсуждаемом предмете, что и требовалось доказать. Копирование в конструкторе ReadOnlyCollection<> и прочие утверждения безумны.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
I>>В прынцыпе, в массиве IEnumerable можно оставить, шоб вообще всё было сильно
_FR>Спасибо, но ваш пример убедительно показывает вашу некомпетентность в обсуждаемом предмете, что и требовалось доказать.
Весомый аргумент
>Копирование в конструкторе ReadOnlyCollection<> и прочие утверждения безумны.
ReadOnlyCollection в нынешней реализации никакой не ReadOnlyCollection, он меняется при чем ты даже не знаешь когда.
А копирование двух массивов вобщем то не шибко дорогая операция.
Заметь — ты не можешь не только критиковать, но и свою версию пояснить не в состоянии.
Здравствуйте, _FRED_, Вы писали:
_FR>Я, признаться, удивлён: говорить о том, что коллекции сделаны не лучшим образом и не знать базовых интерфейсов коллекций _FR>Единственная коллекция с таким свойством — массив, и специально для него было сделано IList.IsFixedSize Property. Об этом, если не ошибаюсь, даже Рихтер писал. Классику всё-таки по диагонали читать не следует, что бы не задавать потом подобных вопросов.
Можно показать, где Рихтер об этом писал, а то я и второе и третье издание читал, и такого не припомню. Если я прав, то может стоит удостовериться сначала, написано ли там такое, прежде чем оскорблять человека, говоря о его некомпетентности и о том, что "классику все-таки по диагонали читать не следует"?
Здравствуйте, samius, Вы писали:
S>Здравствуйте, _FRED_, Вы писали:
_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, изменять данные по индексатору она позволяет. Но, во-первых, это уже детали реализации и, во-вторых, это нигде [я не знаю где] не запрещено документацией. S>Цитата выше утверждает что у read-only коллекций запрещено изменение элементов после создания коллекци без упоминания об исключении в виде массива и его разных реализациях казалось бы одного свойства.
Вопрос к _FRED_'у:
Слав, а можно как-то прокомментировать вот то что написал samius, а то ты как-то скромно оставил именно это предложение без комментариев?
Здравствуйте, MozgC, Вы писали:
MC>Можно показать, где Рихтер об этом писал, а то я и второе и третье издание читал, и такого не припомню. Если я прав, то может стоит удостовериться сначала, написано ли там такое, прежде чем оскорблять человека, говоря о его некомпетентности и о том, что "классику все-таки по диагонали читать не следует"?
Он имеет ввиду книгу, в которой Рихтер выступил в основном комментатором и в которой авторы не раз посыпали голову пеплом из за дизайна первых версий дотнета
Писал на самом деле не Рихтер, а Krzysztof Cwalina. "Design guidelines."
Здравствуйте, Qbit86, Вы писали:
I>>Писал на самом деле не Рихтер, а Krzysztof Cwalina. "Design guidelines."
Q>Тема ветки как бы уточняет название: «Framework Design Guidelines».
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, MozgC, Вы писали:
MC>>Можно показать, где Рихтер об этом писал, а то я и второе и третье издание читал, и такого не припомню. Если я прав, то может стоит удостовериться сначала, написано ли там такое, прежде чем оскорблять человека, говоря о его некомпетентности и о том, что "классику все-таки по диагонали читать не следует"?
I>Он имеет ввиду книгу, в которой Рихтер выступил в основном комментатором и в которой авторы не раз посыпали голову пеплом из за дизайна первых версий дотнета I>Писал на самом деле не Рихтер, а Krzysztof Cwalina. "Design guidelines."
We also decided that arrays will return true from IsReadOnly, but will actually allow setting values using the indexer (which we are trying to fix in RTM as it does not work today).
We also decided that arrays will return true from IsReadOnly, but will actually allow setting values using the indexer (which we are trying to fix in RTM as it does not work today).
MC>Спорное решение..
Сдается им пришлось из за дизайна первых версий выкручиваться.
Потому что это разные интерфейсы (розетки выглядят по-разному).
А>Считай, что метод Add это вставки вилки в розетку
Если Вам близки аналогии из бытового применения электричества, то пожалуй, следующая аналогия будет корректной:
Вызов метод Add в реализации IList, предоставляемой Массивом -- это вставка вилки мощного нагревательного прибора в розетку на маленьком дизель-генераторе. Вроде как и влазит, но работать не будет (при этом ничего не сломается).
Ну и где-то рядом с розеткой есть табличка "не более 500ватт" для тех, кто инструкцию к дизгену не читает.
Здравствуйте, MozgC, Вы писали:
MC>Здравствуйте, Ikemefula, Вы писали:
I>>Писал на самом деле не Рихтер, а Krzysztof Cwalina. "Design guidelines."
MC>Угу, нашел вот: Generic interfaces, IsReadOnly, IsFixedSize, and array.
MC>
We also decided that arrays will return true from IsReadOnly, but will actually allow setting values using the indexer (which we are trying to fix in RTM as it does not work today).
Уклон все-таки сюда:
We decided that there are really not that many fixed size data structures that are not read only. In fact, we only have one – the array. We think that having a property on a very commonly implemented interface that is useful in only one case is not the right thing to do. So we decided to remove IsFixedSize.
_FRED_ пересказал соображения верно, но промахнулся с источником.
Да, массив всего лишь одна такая стандартная структура. Зато очень часто используемая.
MC>Спорное решение..
и то что оно описано в DG не делает его лучше.
Все равно считаю, что fine-grained разделение интерфейсов коллекций на IReadOnly* и I* позволило бы отказаться от сомнительных свойств IsReadOnly, IsFixedSize без комбинаторного взрыва.
Поезд, правда, ушел. И менять что-либо в интерфейсах стандартных коллекций уже поздно.
Однако, IIndexerSettable — это будет венец всему.
Здравствуйте, MozgC, Вы писали:
MC>Здравствуйте, _FRED_, Вы писали:
_FR>>Я, признаться, удивлён: говорить о том, что коллекции сделаны не лучшим образом и не знать базовых интерфейсов коллекций _FR>>Единственная коллекция с таким свойством — массив, и специально для него было сделано IList.IsFixedSize Property. Об этом, если не ошибаюсь, даже Рихтер писал. Классику всё-таки по диагонали читать не следует, что бы не задавать потом подобных вопросов.
MC>Можно показать, где Рихтер об этом писал, а то я и второе и третье издание читал, и такого не припомню. Если я прав, то может стоит удостовериться сначала, написано ли там такое, прежде чем оскорблять человека, говоря о его некомпетентности и о том, что "классику все-таки по диагонали читать не следует"?
Если он об этом и не писал, то это никак не отменяет факта того, что данные вещи требуется знать, более того, вступая в спор о правильности проектирования коллекций. Не из литературы, так из десятиминутного эксперимента. Это же настолько базовые вещи. Вам нужно поработать с интерфейсом, имеющим ряд свойств (не два-три десятка, а столько, что можно пересчитать по пальцам одной руки). Мне как-то странно, что можно приступить к работе, не понимая, что и когда эти свойства делают. Тем более, что все они только на чтение и, как правило, не меняют своего значения в процессе работы.
Если вы пользуетесь IList, например, и не знаете, что означают ReadOnly/IsFixedSize, то о какой компетентности может идти речь?
Если вы открыто высказываете мнение об ошибках проектироващиков, но при этом не в курсе, как проктировалось осуждаемое вами и почему оно именно такое — то не оскоррбляться надо, когда вам рассказывают, как дело было и почему и зачем вышло так, как есть, а мотать на ус, испытывая чувство благодарности за то, что кто-то тратит время, рассказывая вам то, что вы ранее не знали. му должны были научить ещё в ВУЗетребуя перед каждой самостоятельной изыскательной или "научной" работой осветить первым делом то, что уже было сделано до ваших рассуждений и выдумок.
Теперь вспоминайте, что дедушка уже такой старенький, что мог читать ещё того Рихрера
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, MozgC, Вы писали:
_FR>Если вы пользуетесь IList, например, и не знаете, что означают ReadOnly/IsFixedSize, то о какой компетентности может идти речь?
Я лично не использую IList и никаких угрызений совести по поводу незнания его свойств не испытываю. Тем более что при ознакомлении с ним я вижу те же грабли, что и в IList<T>.
_FR>Если вы открыто высказываете мнение об ошибках проектироващиков, но при этом не в курсе, как проктировалось осуждаемое вами и почему оно именно такое — то не оскоррбляться надо, когда вам рассказывают, как дело было и почему и зачем вышло так, как есть, а мотать на ус, испытывая чувство благодарности за то, что кто-то тратит время, рассказывая вам то, что вы ранее не знали. му должны были научить ещё в ВУЗетребуя перед каждой самостоятельной изыскательной или "научной" работой осветить первым делом то, что уже было сделано до ваших рассуждений и выдумок.
Благодарю за потраченное время, но суть всей эпопеи заключена в выделенном. Извиняюсь, но никаких откровений в рассказе я не увидел. Все еще считаю что из старых ошибок получились новые. И вобщем-то все эти рассказы мое убеждение подтверждают.
_FR>Теперь вспоминайте, что дедушка уже такой старенький, что мог читать ещё того Рихрера
И прежде чем науськивать его, перечисляя "второе и третье издание" понять, что первым же делом, и к бабке не ходи, вас отошлют к первому.
Русское издание 2002-го года никак не могло содержать информацию об особенностях реализаций массивом дженериковых интерфейсов, как и о причинно следственных связях этих особенностей.
Если дедушка такой старенький, то наверняка он помнит, что дженерики стали доступны весной 2004-го в первой бете vs2005 и претерпевали множество изменений до релиза. Например, в одной из бетта версий (не помню конкретно которой) при кастинге массива в IList<T> получался полностью иммутабельный объект, т.е. через сеттер индексатора IList<T> изменить содержимое массива было нельзя. Однако в документации той же беты было упоминание о том, что не стоит в дальнейшем рассчитывать на такое поведение. Причин отказа от этого решения я не знаю.
И прежде чем науськивать его, перечисляя "второе и третье издание" понять, что первым же делом, и к бабке не ходи, вас отошлют к первому.
