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> не может быть распакован, так как он и не упаковывается вовсе.