Здравствуйте, Tom, Вы писали:
GIV>>Отсутствие множественного наследования никак не связано с тем что все классы неявно наследуся от System.Object. В нем нет никаких данных так что и проблем с этим не былоб.
Tom>Отсуствие множ. наследование связанно именно с System.Object. Tom>Кстате тоже было и в Delphi, так, что это не я выдумал.
Tom>К примеру
Tom>class Foo : Bar1, Bar2
Tom>{
using Bar1.GetHashCode; // Может, по аналогии?
Tom>}
Tom>..
Tom>..
Tom>..
Tom>Foo foo = new Foo();
Tom>foo.GetHashCode() // невозможно определить какую именно GetHashCode необходимо вызывать
<< RSDN@Home 1.1.4 beta 7 rev. 474 >> =01:19= [Windows XP — 5.1.2600.0]
under «*none*»
Help will always be given at Hogwarts to those who ask for it.
Re[5]: В чём смыл ограничения в наследовании в C#?
Здравствуйте, adontz, Вы писали:
A>Не нашёл ответа, но жутко интересно
A>В чём смысл, что нельзя отнаследоваться от нескольких классов, но можно от одного класса и нескольких интерфейсов? A>Соответсвенно ключевое слово base для вызова конструктора базового типа не оставляет и надежды, что не абстрактных базовых типов может быть два.
A>В Си++ такого ограничения нет и я нигде не встречал критики по этому поводу.
A>Объясните пожалуйста
Как мне кажется, основная проблема — техническая. (остальные объяснения про неявную сложность — отмазки )
А техническая проблема заключается в реализации сборщика мусора, для коего единица сбора — это Object.
Если объект множественно наследован, т.е. инкапсулировал в свое тело несколько Object, то как работать сборщику, если кто-то держит не "головной" объект, а некую его часть — одну из баз?
Да, все это решаемо, но ценой многократного оверхеда по производительности сборщика мусора. Уверен, то пока мест они на это не пойдут, ибо вопрос серьезный и почти политический. Возможно, что лет через несколько, когда скорость сборки мусора станет не критична, к этому вопросу вернутся.
Все-таки, множественное наследование как раз-таки дает бОльшую продуктивность при реализации сложных иерархий.
Re[2]: В чём смыл ограничения в наследовании в C#?
Hello, vdimas!
v> Как мне кажется, основная проблема — техническая. (остальные объяснения v> про неявную сложность — отмазки )
v> А техническая проблема заключается в реализации сборщика мусора, для v> коего единица сбора — это Object.
v> Если объект множественно наследован, т.е. инкапсулировал в свое тело v> несколько Object,
Вот тут вот ни назу не "т.е". Зачем нужно несколько Object? Хоть одну причину назови...
Posted via RSDN NNTP Server 1.9
WBR, Igor Evgrafov
Re[2]: В чём смыл ограничения в наследовании в C#?
Hello, "vdimas"
> А техническая проблема заключается в реализации сборщика мусора, для коего единица сбора — это Object. > > Если объект множественно наследован, т.е. инкапсулировал в свое тело несколько Object, то как работать сборщику, если кто-то держит не "головной" объект, а некую его часть — одну из баз? >
Сборщик мусора тут совершенно не причем. Весь необходимый функционал уже присутствует — достаточно посмотреть на managed указатели. Например, сборщик мусора понимает, что указатель указывает не на объект целиком, а на одно из полей. т.е. сборщик мусора оперирует не единичным указателем, а интервалом (база + размер)
Posted via RSDN NNTP Server 2.0 beta
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[6]: В чём смыл ограничения в наследовании в C#?
Здравствуйте, GarryIV, Вы писали:
GIV>Вот с таким подходом грабель точно будет достаточно... Да и каждый раз писать using на все методы system.object занятие малоприятное.
using Bar1.* ?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Re[7]: В чём смыл ограничения в наследовании в C#?
Здравствуйте, Lloyd, Вы писали:
GIV>>Вот с таким подходом грабель точно будет достаточно... Да и каждый раз писать using на все методы system.object занятие малоприятное.
L>using Bar1.* ?
Неее, это уже ява получится...
Help will always be given at Hogwarts to those who ask for it.
Re[2]: В чём смыл ограничения в наследовании в C#?
Глупости, при единичном наследовании указатель указывает всегда только на объект целиком!
В случае же множественного наследования действительно необходимы указатели на "базы" объекта.
Обращение к полям объекта: указатель на объект + смещение переменной.
Есть, например, класс A, который наследует от B и С. Мы создаем переменную класса A, и должны передать ее в какой-нибудь метод, который ожидает параметр типа С. Нам нужно передавать ссылку не на сам объект А (ссылку на его начало), а ссылку именно на "базу" С (по-другому можно сказать, ссылку на адрес в памяти, с которого начинаются переменные класа C).
] Все-таки, множественное наследование как раз-таки дает бОльшую продуктивность при реализации сложных иерархий.
Т.е. при множественном наследовании очень легко создать сложную иерархию. Но со временем иерархия вырастает и становится по сути своей большим карточным домиком, из которого ни вытащить ничего нельзя, ни добавить, без появления багов. Заказчикам это не очень нравится, потому что мало кто из разработчиков хочет получить такой домик в наследство, и как следствие, сильную головную боль. Поэтому в C# нет множественного наследования.
Здравствуйте, GarryIV, Вы писали:
GIV>Я только говорил, что не вижу причин по которым именно System.Object мешает реализовать множественное наследование. Именно от System.Object сторонних эффектов не будет как бы его не использовали наследники. ИМХО достаточно написать в спецификации, что для объекта любого класса как бы он не наследовался подобъект System.Object будет только один. Для этого даже не надо явно вводить два типа наследования...
Лично я подозреваю, что собака порылась во взаимодействии с GC. Не секрет, что указатели на объекты "множественных" типов начинают вести себя довольно-таки нетривиально при приведениях (по крайней мере, в С++). Возможно, сложности с получением графа достижимости в MI-системах и привели к отказу от поддержки MI вообще.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, adontz, Вы писали:
A> В чём смыл ограничения в наследовании в C#? A> Не нашёл ответа, но жутко интересно
Такова main stream объектная модель. Попробуйте только добавить множественное наследование в С# и Вы тот час же получите аналогичные С++ сонмища правил, исключений из правил и т.д. Main stream объектная модель пригодна только для обычного простого наследования, точнее будет сказать — для расширения типов. Это не значит что она плохая. Она оптимальна для модели расширения существующих типов, но дело в том, что расширять можно только один тип — а это как раз и есть "одиночное" наследование.
Грамотно спроектированной объектной моделью, органично включающей в себя то что принято называть множественным наследованием, является, например, объектная модель реализованная в языке программирования Zonnon. Она не является main stream объектной моделью — не оперирует понятием расширения типов, а оперирует понятием пересмотра определений (refine definition).
P. S.
Вся существующая критика множественного наследования на самом деле является не критикой множественного наследования самого по себе, а лишь только критикой реализации множественного наследования в "main stream" объектной модели, в частности ее реализации в С++. В самом по себе множественном наследовании, вообще-то, ни чего страшного нет, только не надо его понимать так как это сделано в С++.
СГ>P. S. СГ>Вся существующая критика множественного наследования на самом деле является не критикой множественного наследования самого по себе, а лишь только критикой реализации множественного наследования в "main stream" объектной модели, в частности ее реализации в С++. В самом по себе множественном наследовании, вообще-то, ни чего страшного нет, только не надо его понимать так как это сделано в С++.
В догонку...
Далеко за примерами ходить не надо. В этой же ветке как раз идет критика якобы множественного наследования; предлагаются варианты с проблемами в сборщике мусора, проблемы с единым предком, рассматриваются "указатели на базы объекта" и т.д. и т.п. НО!!! всё это лишь критика попытки реализации множественного наследования как раз в рамках стандартной объектной модели. Конечно, очевидно, что в рамках main stream объектной модели множественное наследование очень сложное и запутанное явление, ведь оно ей не присуще по рождению. Но это не значит что идея того что обозначает термин "множественное наследование" сама по себе глупа. Просто нужна совершенно другая объектная модель!
Здравствуйте, Varg, Вы писали:
V>2 vdimas
V>] Все-таки, множественное наследование как раз-таки дает бОльшую продуктивность при реализации сложных иерархий.
V>Т.е. при множественном наследовании очень легко создать сложную иерархию. Но со временем иерархия вырастает и становится по сути своей большим карточным домиком, из которого ни вытащить ничего нельзя, ни добавить, без появления багов. Заказчикам это не очень нравится, потому что мало кто из разработчиков хочет получить такой домик в наследство, и как следствие, сильную головную боль. Поэтому в C# нет множественного наследования.
у меня головная боль от чтения подобных необоснованных умозаключений.
Смотри. Берем иерархию стримов. Берем нормальную иерархию, не такую как в дотнет или дельфи.
Есть еще MemoryStream, NetworkStream и т.д. и т.п.
Соответственно, использование очень строгое, мы определяем в сигнатурах ф-ий не просто Stream, как в дотнет, а именно InputStream или OutputStream, т.е. добавляем семантический статический контроль. (путем типизации)
Представляешь, если бы это все было иерархией интерфейсов. как устала бы рука все это имплементировать. А при наличии множественного наследования там просто копейки на класс получились. (реальная либа на C++)
Соотвественно, поддерживать маленькую горку кода все же легче, чем огромную гору.
Re[2]: В чём смыл ограничения в наследовании в C
От:
Аноним
Дата:
24.06.05 09:59
Оценка:
Можно бесконечно спорить и приводить обоснованные умозаключения по поводу "хорошести" множественного наследования, но
в C# его нет, и скорее всего из ЭКОНОМИЧЕСКИХ соображений. Иначе надо будет признать, что в Microsoft не умеют считать деньги
V>Все-таки, множественное наследование как раз-таки дает бОльшую продуктивность при реализации сложных иерархий.
При реализации сложных иерархий начинают очень сильно проявляться сторонние эффекты!!!!
И в этом случае на тестирование и разруливание этих самых сторонних эффектов тратится сил гораздо больше чем на
реализацию Mixin-класса.
Это мое мнение, выстраданное не в одном проекте на C++.
)
