cdtyjv1) ICollection не имеет метода Add. ICollection<> имеет. IDictionary<> имеет. Даже IDictionary имеет. А ICollection нет. То есть это абсолютно бессмысленный интерфейс, который не добавлять практически ничего полезного к IEnumerable. В итоге, если у меня есть в руках ICollection, я не могу добавить туда элемент. Стыд и срам.

свойство Count. а у IEnumerable его нет, который вообще может быть бесконечной «коллекцией».

ICollection и ICollection<T> -- разные по смыслу и замыслу интерфейсы, это совсем не тоже самое «только с типом». это и касается IDictionary/IDictionary<T>.

но детский неокрепший мозг видит одинаковые слова , и его мир начинает рушится...

cdtyjv2) Нет общей иерархии классов. ICollection<> не имеет ничего общего с ICollection. С Dictionary та же проблема. В итоге, что бы определить, что у меня в руках коллекция, нужно писать трехэтажные неэффективные выражения через рефлекшн.

конечно, а с какого перепугу, это вдруг, должно? я не понял, зачем себя ставить в такую идиотскую ситуацию, чтобы выяснять «что за коллекция»?

cdtyjv3) Иерархия некоторых коллекций просто повергает в ужас. Например, ConcurrentDictionary<> имплементирует IDictionary<>, логично. Наверное, тогда и типизированный ConcurrentBag<> будет имлементировать ICollection<>, правда? Неа, он имплементирует ICollection, и какой-то совершенно идиотский типизированный producer-consumer.

всё логично, если подумать тем местом, что называется голова. я же сказал ICollection и ICollection<T> никак не коррелируют друг с другом, да и были спроектированы с довольно большим интервалом времени. кое что доосмыслилось при проектировании типизированных коллекций, а старое менять нельзя, надеюсь сам понимаешь почему. очень надеюсь.

cdtyjv4) Нет кучи полезных специализированных коллекций. Нет read-only коллекций (вернее, есть одна - для списка, а set? а dictionary?), конкаррент коллекции появились только в 4.0 и имеют отвратительнейшую иерархию, нет synchronized-оберток, как в Java. Поэтому для реализации банальнейшего сценария - выдать пользователю unmodifiable коллекцию, что бы он не наломал дров - нужно писать какие-то свои обретки. А с имеющейся иерархией попробуйте ка написать универсальную такую обертку

всё там есть. IReadOnlyDictionary, IReadOnlyCollection и IReadOnlyList.

для ISet видимо это без надобности, т.к. есть IsReadOnly на такой редкий случай.

cdtyjvВ Джава этой информации нет, type erasure. Верите-нет, но она на практике нафиг никому не нужна.

когда была жёсткая необходимость покодить на Java, я чуть не блеванул. серьёзно. хотя знаю, что имеются толпы миллионов Java-кодеров, которые вполне комфортно себя чувствуют в среде Java, но лично я после C# на Java чувствовал себя вышвырнутым за пределы нормальной цивилизации.

cdtyjvВопрос - кто проектировал это?

много людей, соответственно до идеала конечно далеко.

cdtyjvВам комфортно работать с коллекциями в .Net?

вполне.

cdtyjv,

чтоб понять, почему ICollection<T> никак не может наследоваться от ICollection, рассмотрим вот такую коллекцию:




благодаря тому, что .NET точно знает тип и размер элементов коллекции, он может разместить их эффективно в непрерывном блоке памяти .

приведём эту коллекцию к ссылке на интерфейс ICollection, который представляет собой коллекцию, хранящую какие-то Object, т.е. ссылки на объекты в куче.

стоит заморачиваться и объяснять, почему это в принципе невозможно?

с другой стороны может возникнуть вопрос, почему же тогда можно привести типизированную коллекцию к нетипизированному IEnumerable? ответ прост. потому что IEnumerable это вовсе не коллекция по сути. это интерфейс, который содержит метод, возвращающий итератор. итератор же упаковывает значение элемента и возвращает ссылку (это называется boxing, и в случае, если не применяется duck typing), или просто ссылку, если элементы коллекции являются экземплярами класса.

в Java таких заморочек нет, потому что там нет типов-значений, что позволяет .NET уделывать Java как котёнка в плане производительности.

Где-то в степив типизированых коллекциях, в случае со значениями, упаковки не проходит, там даже итератор живет живет в виде структуры.
За это, в свое время воевали наши отцы и деды.

http://msdn.microsoft.com/ru-ru/library/system.collections.ienumerator.current.aspx

Где-то в степиУпаковка в правильно написаны дженерик конструкциях не должна приветствоваться

чуть больше веселья cо специальным Nullable<T> типом

Где-то в степиа чем же он специальный? это обыкновенная структура? со своим сахаром

сахар это всего лишь пол беды, попробуй вот это:




что будет в some в обоих случаях?

а с рефлекшеном там вообще целая эпопея.

Где-то в степину а что Вас смутило? упаковка nullable имеет свои определенные правила.

поэтому я и говорю что это специальный тип, а не обыкновенная структура.

Где-то в степиравно как и распаковка

Nullable<T> не может быть распакован, так как он и не упаковывается вовсе.

Где-то в степичем же он специальный, то что его поведение описано его реализацией?

ни один struct кроме Nullable<T> не может "упаковаться" в null.

это выглядит, как естественное поведение, но для некоторых становится неожиданным, ведь как же? Nullable<T> -- "это ж обыкновенная структура".

Где-то в степиMyClass - специальный тип, так как не имеет публичного конструктора, транзитивно?

ни единой параллели.

Где-то в степинапишите свою, тут проблем нет или вы считаете что это шаманство компилятора?

шаманство конечно. struct это тип, передающийся по значению, никаких ссылок. при упаковке/распаковке мы гарантированно получаем значение и может определить тип упакованных данных. в случае с Nullable, тип "упакованных" данных легко потерять.

Arm79Разумеется, можно обойтись и без визуального (без визарда), но неудобно.

визуально можно сотворить лишь какой-нибудь примитив. а примитиву наследование не впилось.

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

может только студентам каким, корявые лабы монстрячить.

Arm79Так может говорить только человек, не работавший с Delphi.

я работал с делфи. однако со своей стороны уверю вас, если в вашем приложении грубо говоря больше 3-х форм, то про визуальный редактор, как основной инструмент, лучше забыть. и на делфи ровно такая же ситуация. представьте, что у вас этих форм от 100 и выше. скорее всего вы задумаетесь об автоматизации, чтобы не делать каждую форму вручную, и помашете ручкой виз. редактору. иначе я очень вам сочувствую. хотя.... если вам платят за бессмысленную и беспощадную работу в независимости от сроков, то конечно-конечно, надо растягивать удовольствие на месяцы и годы. как у нас обычно бывает.

Arm79Разумеется, нет. Ведь если писать свой НОРМАЛЬНЫЙ фреймворк для генерации форм, времени уйдет больше, чем вручную. Посмотрите, сколько труда вложено в XAF. Но суть не в этом. Если форм - 200, 300 или сколько там, - это не важно. Важно сколько ТИПОВ этих форм. А типов как раз таки не так много, и наследование там очень удобно.

да какие проблемы, я не понимаю

Windows Forms Visual Inheritance