а почему не может быть и для того, и для другого?
к тому же если бы речь шла только о защищенности легче было бы не делать foreach вовсе и оставить лишь оператор for для индексации


мож Гейтсу письмо написать - "Билл, зачем???"

Это сообщение отредактировал(а) 0000 - 6.11.2007, 13:03

если код не подвергается риску, то так и делается. Используется for (внутри методов класса, для локальных или закрытых коллекций). Даже больше скажу: for не потерял актуальности, даже наоборот... Раньше в for можно было только через Array.Lenght работать, теперь  (для коллекций) специально введено свойтсво Count.
Зачем оно, если нужно работать только через foreach ?

Если же коллекция предоставляется наружу, то нужно максимально защитить и ее содержимое и содержимое всего объекта, содержащего коллекцию. ReadOnly не спасает. Get Property - не спасает. IEnumerator - спасает.

фактически получается, что IEnumerator повяился для того, чтобы можно было пользоваться оператором foreach..
но тут суть-то в том, что IList явно наследует IEnumerator..если бы дело было только в надежности достаточно было бы того, что ICollection уже наследует IEnumerator и в IList лишний раз прописывать это наследование было бы не нужно

если не секрет, что за сайты? интересно было бы почитать дискуссию.

http://www.rsdn.ru/Forum/message/2719680.aspx

то есть получается для более быстрой компиляции?

мож попробывать, а ваще загадка М$

но все равно непонятно..ну даже если получаем мы список интерфейсов, но ведь для полного списка нам все равно нужно проверить ICollection, чтобы взять его интерфейсы..мож там еще и другие есть

Jlekc, понятно, похоже вопрос снят, это просто путаница при анализе метаданных. В аттаче один и тот же код, просматриваемый как проект и как внешняя сборка.





Присоединённый файл ( Кол-во скачиваний: 7 )
 ifaces.png 4,71 Kb

имхо это лишь ответ на то, что происходит, но не на вопрос - ПОЧЕМУ ТАК?

да нет, не скерет. самая известная публикация после ECMA334 
или поиск по гуглу с ключом "re-implementation interface"
Только в том-то и дело, что не пишут... С классами - всем все давно понятно. Interface Mapping работает...

Jlekc, почитал... "для пущей понятности" и "для повышения быстродействия - уменьшения рефлексии" и т.п. ... как-то неубедительно. Если б я не знал как часто используется рефлекссия (практически везде) ... может быть и поверил бы. Но тогда с .Net на плюсы обратно переходить надо, если уж ТАК о быстродействии заботятся...

По поводу аттача - MSIL отличается, это в той ссылке, что я кидаю. упоминается.

Да тоже не убидили, но другое напровление обсуждения. Решил последить за развитием, и тут запостил если кому интересно

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

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

это явный баг в jit-компиляторе, т.к. il-код валидный в обоих случаях, там вроде пишут, что уже поправили. вопрос в том, зачем это было делать таким запутанным, что даже стандарт ответа не может дать однозначного. здравствуй дядя Вирт со своим Обероном 

Добавлено @ 17:27
0000, чёрт его знает, если задуматься, то из метаданных эту информацию можно вытянуть, например в рефлекторе всё нормально показывается. но, насколько я понимаю, это не будет однозначным ответом.

может быть это просто недочёт стандартного просмоторщика объектов студии.