Смутил один момент:

Интерфейс IList наследует интерфейсы ICollection и IEnumerable. Хотя ICollection уже наследует IEnumerable.

Тоже самое с IDictionary - он тоже наследует и ICollection, и IEnumerable.

Тоже самое с интерфейсами в System.Collections.Generic.

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

Тогда c какой целью явно указывается IEnumerable в предках? Для пущей ясности?

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

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


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

теперь будет работать


Рихтер, "наследование интерфейсов":

tol05, 
твой пример с классами - тут вопросов нет, все чинно с явной реализацией методов интерфейсов...

а вопрос-то в другом...
зачем при реализации IList явно прописывать наследование и от ICollection и от IEnumerable, ведь ICollection уже наследует IEnumerable...тут суть не в классах, а в самих интерфейсах...

лично мне это тоже не совсем понятно зачем так делают

да по тем же причинам.
Я же писал: реализация интерфейса наследнику не передается
допустим

так можно

так нельзя

а если в каком-нибудь промежуточном интерфейсе повторить наследование, то

видно, как показал реальный юзинг интерфейсов, иногда нужно F1() вызывать через ссылку на базовый интерфейс, а иногда - через ссылку на производный. 
В зависимости от того, к ссылке какого интерфейса в реальном коде приводится объект, будет зависеть интерфейс доступа у объекту (с любом случае ведь работа будет с объектом, а не с декларацией его возможностей), ну и сами функциональные возможности. 

Это сообщение отредактировал(а) tol05 - 4.11.2007, 22:02

согласно твоей логике так делать нельзя???

или мы опять недопоняли друг друга??   

может вопрос по разному поняли....хм..но ведь в реализации ArrayList никаких явных методов интерфейсов нет, если верить перехоту по "Go to definition"


Это сообщение отредактировал(а) 0000 - 4.11.2007, 22:38

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

но...
в IList и ICollection вроде нет одинаковых

'IMyInterface.F1': explicit interface declaration can only be declared in a class or struct, что вполне логично, т.к. new задаёт новую реализацию, а не новый интерфейс. интерфейс не может специфицировать необходимость реализации одного и тоже интерфейса более одного раза. в этом  просто нет смысла, интерфейс в каждом конкретном типе всегда имеет только одну реализацию.


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

я имел в виду явную реализацию интерфейса.
так нельзя

так можно


а по поводу нескольких реализаций в одном типе... тут тонкий момент  
работа interface mapping :

запускаем и получаем 

раскомментируем, запускаем и получаем

т.е. оба метода, в принципе, являются реализацией интерфейса. Мы меняем сопоставление реализации с интерфейсом. И имеем две реализации одного и того же интерфейса.

явная реализация интерфейса не передается в наследовании от класса к классу..но ведь если твой IA унаследовать от скажем IB, а тот от IC, то в классе D ты сможешь выполнить явную реализацию всех методов из всех трех интерфейсов...не обязательно при этом явно прописывая наследоание IA от IC..

Явная реализация интерфейсов, хмм.
Разговор начился с интерфейса IList, если посмотреть где он используеться - ArrayList например. 
При наследовании IList, также наследуеться и вся цепочка интерфейсов: ICollection, IEnumerable.
И почему-то невидно никакой явной реализации интерфейсов.

Похоже это замечание было самым верным


Добавлено через 14 минут и 51 секунду
ЗЫ: Прошолся по сборке генератором доков Sandcastle.
В сборке два класса - один наследует IList, второй IList и всю цепочку его интерфейсов.
Как и ожидалось в хелпаке для первого класса видно только IList, для второго все интерфейсы.

вот я про то же и говорил, что при желании явно реализовать методы из IEnumerable можно, явно не наследуя..

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

Одним словом, написал в этом топике много, да большей частью, не по теме 

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


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




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

Поскольку любая коллекция содержит в себе массив, то для скорости было бы логичнее, чтобы каждая коллекция предоставляла открытое свойство типа Array. Но это огромная дыра в защите кода. Дырище просто... Поэтому IEnumerable используется для защищенности коллекции а не для скорости.

А во-вторых... Поскольку я влез в тему с агресивными опровержениями  то для меня было делом чести протестить все варианты. Даже надуманные. И должен сказать, что где бы ни было заявлено наследование интерфейса (не в иерархии классов, реализующих интерфейс, а именно в иерархии наследования интерфейсов), доступ к этому интерфейсу одинаков...

А по поводу ре-имплементации интерфейса в иерархии наследования интерфейсов - ни ECMA, ни MVP с "русско-неговорящих" сайтов - никто ничего не говорит. А некоторые (и я в их числе  ) - так и говорят: не знаем.


вот так вот-с 

а почему не может быть и для того, и для другого?
к тому же если бы речь шла только о защищенности легче было бы не делать 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, чёрт его знает, если задуматься, то из метаданных эту информацию можно вытянуть, например в рефлекторе всё нормально показывается. но, насколько я понимаю, это не будет однозначным ответом.

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