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

S>>>А потом, если arr.IsReadonly все-таки true, то его наверно изменять нельзя через индексатор?
_FR>>Ну ёлки-палки. Неужели так сложно погуглить и почитать о том, что означают свойства базовых интерфейсов коллекций И как можно о чём-то говорить, не имея таких примитивных знаний?

S>http://msdn.microsoft.com/en-us/library/bb346454.aspx
S>

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

S>Погуглил. После этого ты будешь утверждать что изменение элементов массива запрещено?

После этого я скажу, что где-то читал, что IsFixedSize (именно то, что вам сейчас хочется) оказался не нужен в базовых интерфейсах и поддержку его в базовом АПИ сочли излишней. Единственно общее место (не беря в расчёт очень редкую специфику), где IsFixedSize необходим — массив. И держать IsFizedSize в очень общем интерфейсе, заставляя каждую пользовательскую коллекцию его реализовывать, не нужно. В generic оставили один признак — IsReadOnly, покрым этим 99% случаев. Поэтому, если вам это важно, обработайте этот кейс, проверив объект на IList или на массив. Последнее возможно без приведений типов.

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

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

S>>>>А потом, если arr.IsReadonly все-таки true, то его наверно изменять нельзя через индексатор?
_FR>>>Ну ёлки-палки. Неужели так сложно погуглить и почитать о том, что означают свойства базовых интерфейсов коллекций И как можно о чём-то говорить, не имея таких примитивных знаний?

S>>http://msdn.microsoft.com/en-us/library/bb346454.aspx
S>>

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

S>>Погуглил. После этого ты будешь утверждать что изменение элементов массива запрещено?

_FR>После этого я скажу, что где-то читал, что IsFixedSize (именно то, что вам сейчас хочется) оказался не нужен в базовых интерфейсах и поддержку его в базовом АПИ сочли излишней. Единственно общее место (не беря в расчёт очень редкую специфику), где IsFixedSize необходим — массив. И держать IsFizedSize в очень общем интерфейсе, заставляя каждую пользовательскую коллекцию его реализовывать, не нужно. В generic оставили один признак — IsReadOnly, покрым этим 99% случаев. Поэтому, если вам это важно, обработайте этот кейс, проверив объект на IList или на массив. Последнее возможно без приведений типов.
В том и предыдущем сообщении я больше интересуюсь возможностью изменения элементов массива через индексатор. Что-то мне подсказывает, что IsFixedSize тут не поможет. IsReadOnly я использовать побоюсь, т.к. даже у одной и той же сущности он возвращает разные результаты. Допустим, сейчас я разберусь в этой ситуации, а что делать когда через пол-года увижу очень неочевидный код у себя? Опять разбираться в этом вопросе? Предпочту табу на это свойство.

Единственный разумный выход — тестировать на is T[].
Кстати, от IList<T> к IList без приведения типов не перейти.

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

А>>>>>кто мне объяснит зачем мне доступен метод Add, который всегда будет кидать эксепшн?
Q>>>>«Framework Design Guidelines», глава «9.7 Optional Feature Pattern».
S>>>Есть рецепт, как можно понять, можно ли вызывать метод IList<T>.Add без получения исключения и даункастинга?

_FR>>В этом суть паттерна и заключена, что на все подобные кейсы "есть рецепт". Подробнее ознакомиться можно здесь.

S>Хорошо, как понять можно ли использовать индексатор списка на запись?

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

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

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

А>>>>>>кто мне объяснит зачем мне доступен метод Add, который всегда будет кидать эксепшн?
Q>>>>>«Framework Design Guidelines», глава «9.7 Optional Feature Pattern».
S>>>>Есть рецепт, как можно понять, можно ли вызывать метод IList<T>.Add без получения исключения и даункастинга?

_FR>>>В этом суть паттерна и заключена, что на все подобные кейсы "есть рецепт". Подробнее ознакомиться можно здесь.

S>>Хорошо, как понять можно ли использовать индексатор списка на запись?

_FR>Пытаясь вернуться на продуктивный путь: когда-нить это было нужно? Причем, в отрыве от массива. Никакой разумной структуры данных кроме массива с таким свойством на ум не приходит.
Реально — нет.
Я лишь докапываюсь к выделенному. Использовать подобные вещи без глубокого изучения и понимания можно. Но считать это верным и красивым решением я отказываюсь.
Считаю что в программировании есть куда более интересные и полезные вещи, чем запоминание _таких_ тонкостей.

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

A>>Смысла в это всё равно нет, потому что я лично сам встречался со случаями когда коллекция ReadOnly/FixedSize иногда. Интерфейсами такое не обозначить.
S>Впрочем, можно было бы сделать аналог QueryInterface, который бы в динамике решал, возвращать ли или нет запрашиваемую грань.

Проще свойствами. И если они как-то нелогично работают у массива это не значит что путь в целом неправильный.

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

А>>>>>>>кто мне объяснит зачем мне доступен метод Add, который всегда будет кидать эксепшн?
Q>>>>>>«Framework Design Guidelines», глава «9.7 Optional Feature Pattern».
S>>>>>Есть рецепт, как можно понять, можно ли вызывать метод IList<T>.Add без получения исключения и даункастинга?

_FR>>>>В этом суть паттерна и заключена, что на все подобные кейсы "есть рецепт". Подробнее ознакомиться можно здесь.

S>>>Хорошо, как понять можно ли использовать индексатор списка на запись?

_FR>>Пытаясь вернуться на продуктивный путь: когда-нить это было нужно? Причем, в отрыве от массива. Никакой разумной структуры данных кроме массива с таким свойством на ум не приходит.
S>Реально — нет.

Тогда это разговор примерно такого же уровня, как "Мне нужен класс Form у которого небыло бы свойства Caption, поскольку он мне не нужен, а раз такого нет — архитектура дотнета отстой".

S>Я лишь докапываюсь к выделенному. Использовать подобные вещи без глубокого изучения и понимания можно. Но считать это верным и красивым решением я отказываюсь.

Как раз таки generic-коллекциях всё упрощено: вам же с одной стороны хочется "богатства" (узнать то, узнать другое) с другой вы не хотите "глубоко изучать" Одно ваше желание противоречит другому.

Касательно выделенного: я рассчитывал, что вы знаете о том, какие свойства и для чего имеются в коллекциях, а оказалось, что это не так. Так вот в дженерик-коллекциях есть разделение только на риддонли и неридлонли. В не-дженерик есть ещё и IsFixedSize, который просто не нужен в подавляющем большинстве случаев. Но нигде, например, нет CanAdd/CanRemove. А почему бы и их не вынести так же как отдельные интерфейсы? Вот здесь уже пора почувствовать "комбинаторность". А требование такого свойства от IList<> или от IList ничем не лучше любого другого надуманного ("можно ли использовать индексатор списка на запись") свойства.

S>Считаю что в программировании есть куда более интересные и полезные вещи, чем запоминание _таких_ тонкостей.

Каких "таких" мне не ясно, но если это ваше оправдание незнанию ннекоторых вещей, то мне всё равно.

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

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

A>>>Смысла в это всё равно нет, потому что я лично сам встречался со случаями когда коллекция ReadOnly/FixedSize иногда. Интерфейсами такое не обозначить.
S>>Впрочем, можно было бы сделать аналог QueryInterface, который бы в динамике решал, возвращать ли или нет запрашиваемую грань.

A>Проще свойствами. И если они как-то нелогично работают у массива это не значит что путь в целом неправильный.
Мне сложно назвать правильным путь, в рамках которого одна из наиболее часто используемых сущностей ведет себя нелогично, либо логика ее работы не очевидна, а на счет остальных нельзя сказать, можно ли изменять их элементы.

Мне не нравится это решение, но я готов с ним мириться и не собираюсь наводить во фреймворке порядок.

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

S>>>Погуглил. После этого ты будешь утверждать что изменение элементов массива запрещено?
_FR>>После этого я скажу, что где-то читал, что IsFixedSize (именно то, что вам сейчас хочется) оказался не нужен в базовых интерфейсах и поддержку его в базовом АПИ сочли излишней. Единственно общее место (не беря в расчёт очень редкую специфику), где IsFixedSize необходим — массив. И держать IsFizedSize в очень общем интерфейсе, заставляя каждую пользовательскую коллекцию его реализовывать, не нужно. В generic оставили один признак — IsReadOnly, покрым этим 99% случаев. Поэтому, если вам это важно, обработайте этот кейс, проверив объект на IList или на массив. Последнее возможно без приведений типов.
S>В том и предыдущем сообщении я больше интересуюсь возможностью изменения элементов массива через индексатор. Что-то мне подсказывает, что IsFixedSize тут не поможет.

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

S>IsReadOnly я использовать побоюсь, т.к. даже у одной и той же сущности он возвращает разные результаты.

Нет. Каждый конкретный раз возвращается вполне определённое значение. Если вы запутались в трёх соснах, то я в этом не виноват.

S>Допустим, сейчас я разберусь в этой ситуации, а что делать когда через пол-года увижу очень неочевидный код у себя? Опять разбираться в этом вопросе? Предпочту табу на это свойство.

Я, например, делаю совсем по-другому.

S>Единственный разумный выход — тестировать на is T[].

Говорить о каком-то "разумном выходе" в более чем гипотетическом примере я нахожу странным.

S>Кстати, от IList<T> к IList без приведения типов не перейти.

Спасибо, не знал.

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

_FR>Тогда это разговор примерно такого же уровня, как "Мне нужен класс Form у которого небыло бы свойства Caption, поскольку он мне не нужен, а раз такого нет — архитектура дотнета отстой".

Да нет же, архитектура Дотнета действительно отстой :)

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

_FR>Здравствуйте, Аноним, Вы писали:

А>>>>конкретные вещи:
А>>>>есть розетки на 360, а есть на 220В. Розетка в данном случае — это интерфейс.
А>>>>Я не могу вставить вилку 220 в 360.
А>>>>Считай, что метод Add это вставки вилки в розетку

_FR>>>А кто вам _обещал_ какую-то конкретную розетку или вилку? Чем одна розетка\вилка лучше другой? Ничем, они равноправны. А переходники у любого _квалифицированного_ путешественника должны быть в наличии. Из приведённого вами примера виднен лишь недостаток квалификации

_FR>>>Продолжайте, весилите публику в том же духе.

А>>по сути ответа на конкретный пример не услышал — следовательно, сказать нечего

_FR>Я тоже не услышал выше ответов по сути. Однако вы что-то всё-таки в ответ, не по сути, но сказали. Следовательно, ваш вывод о том, что сказать нечего мне — ошибочен. Качайтесь :о)

А вы, я смотрю, любитель казуистики. Я вам привожу конкретику, а вы мне про "Чем одна розетка\вилка лучше другой?".
Не надо много писать мне философии, давайте кратко и по делу.
Если непонятен мой позыв, повторю: не надо человеку показывать возможность что-то сделать, но при этом не делать этого.

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

A>>>>Смысла в это всё равно нет, потому что я лично сам встречался со случаями когда коллекция ReadOnly/FixedSize иногда. Интерфейсами такое не обозначить.
S>>>Впрочем, можно было бы сделать аналог QueryInterface, который бы в динамике решал, возвращать ли или нет запрашиваемую грань.

A>>Проще свойствами. И если они как-то нелогично работают у массива это не значит что путь в целом неправильный.
S>Мне сложно назвать правильным путь, в рамках которого одна из наиболее часто используемых сущностей ведет себя нелогично, либо логика ее работы не очевидна, а на счет остальных нельзя сказать, можно ли изменять их элементы.

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

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

_FR>>Тогда это разговор примерно такого же уровня, как "Мне нужен класс Form у которого небыло бы свойства Caption, поскольку он мне не нужен, а раз такого нет — архитектура дотнета отстой".
Q>Да нет же, архитектура Дотнета действительно отстой

Ну чё, с блекджеком и шлюхами?

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

_FR>>>Пытаясь вернуться на продуктивный путь: когда-нить это было нужно? Причем, в отрыве от массива. Никакой разумной структуры данных кроме массива с таким свойством на ум не приходит.
S>>Реально — нет.

_FR>Тогда это разговор примерно такого же уровня, как "Мне нужен класс Form у которого небыло бы свойства Caption, поскольку он мне не нужен, а раз такого нет — архитектура дотнета отстой".
Он и есть такого уровня. Я что, не могу выразить свое несогласие с решением? Я ведь не предлагаю переписать дотнет или бойкотировать его?

S>>Я лишь докапываюсь к выделенному. Использовать подобные вещи без глубокого изучения и понимания можно. Но считать это верным и красивым решением я отказываюсь.

_FR>Как раз таки generic-коллекциях всё упрощено: вам же с одной стороны хочется "богатства" (узнать то, узнать другое) с другой вы не хотите "глубоко изучать" Одно ваше желание противоречит другому.
Богатства там нет.

_FR>Касательно выделенного: я рассчитывал, что вы знаете о том, какие свойства и для чего имеются в коллекциях, а оказалось, что это не так. Так вот в дженерик-коллекциях есть разделение только на риддонли и неридлонли. В не-дженерик есть ещё и IsFixedSize, который просто не нужен в подавляющем большинстве случаев. Но нигде, например, нет CanAdd/CanRemove. А почему бы и их не вынести так же как отдельные интерфейсы? Вот здесь уже пора почувствовать "комбинаторность". А требование такого свойства от IList<> или от IList ничем не лучше любого другого надуманного ("можно ли использовать индексатор списка на запись") свойства.
Я не требовал свойства.

S>>Считаю что в программировании есть куда более интересные и полезные вещи, чем запоминание _таких_ тонкостей.

_FR>Каких "таких" мне не ясно, но если это ваше оправдание незнанию ннекоторых вещей, то мне всё равно.
_таких_ — это запоминание того, что IList.IsReadOnly возвращает одно, а IList<T>.IsReadOnly — другое значение; какое из них нужно использовать для того что бы что-то узнать о коллекции, и т.п.
Забивать этим голову я не собираюсь, кому бы ни было все равно.

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

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

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

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

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

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

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

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

>Есть рецепт, как можно понять, можно ли вызывать метод IList<T>.Add без получения исключения и даункастинга?

Есть.

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

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

>>Есть рецепт, как можно понять, можно ли вызывать метод IList<T>.Add без получения исключения и даункастинга?

I>Есть.
видимо if(list.GetType().IsArray) ?

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

I>>Есть.
S>видимо if(list.GetType().IsArray) ?

Предположим, да. Что дальше ?

Здравствуйте, Аноним, Вы писали:

[...]
А>как реализовать это вопрос другой. я говорю про то, что если у вас есть кнопка на телефоне Позвонить, то она должна звонить, а не говорить мне "я не могу это сделать, т.к. кнопку воткнули для совместимости с общим модулем управления клавиатурой"
Возьмите свой мобильный телефон (или у друга если нет своего... Если нет друга, то купите! Телефон естественно). Выньте из него аккумулятор и нажмите кнопку Позвонить. Ну что, позвонил?

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

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

I>>>Есть.
S>>видимо if(list.GetType().IsArray) ?

I>Предположим, да. Что дальше ?
Ничего. Я получил ответ на вопрос, который терзал меня. Всем спасибо.