Вот спорю с коллегой на работе, подскажите есть ли множественное

← →
Rule © (2004-08-10 09:44) [0]

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

← →
Думкин © (2004-08-10 09:58) [1]

А что спорить? Нету. А зачем?

← →
Ega23 © (2004-08-10 10:00) [2]

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

← →
Skyle © (2004-08-10 10:01) [3]

Удалено модератором
Примечание: Личная переписка

← →
VMcL © (2004-08-10 10:03) [4]

>>Rule © (10.08.04 09:44)

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

P. S. Ну и как правильно отметил [1]: а зачем? :)

← →
Юрий Зотов © (2004-08-10 10:03) [5]

1. Сабж - нет.
2. Как обходится - по-разному, от задачи зависит.
3. Как реализовать - написать свой компилятор.

← →
Anatoly Podgoretsky © (2004-08-10 10:03) [6]

В большинстве языков этого нет, вот и в СиДиез убрали.

← →
Игорь Шевченко © (2004-08-10 10:06) [7]

Думкин © (10.08.04 09:58) [1]

> А зачем?

Затем же, зачем в С++, не так ли ?

← →
Думкин © (2004-08-10 10:06) [8]

Удалено модератором
Примечание: Личная переписка

← →
Думкин © (2004-08-10 10:07) [9]

> [7] Игорь Шевченко © (10.08.04 10:06)

Я не спорю, а спрашиваю. Мне вот напрямую пока никак. Обходился, хотя были иногда желания. :)

← →
Игорь Шевченко © (2004-08-10 10:09) [10]

Думкин © (10.08.04 10:07) [9]

Мне, например, из-за его отсутствия приходится писать лишний код. Иногда напрягает.

← →
Думкин © (2004-08-10 10:10) [11]

> [10] Игорь Шевченко © (10.08.04 10:09)

Да, для обхода приходится попотеть. Видимо, есть зачем. :)
Я потел.

← →
han_malign © (2004-08-10 10:12) [12]

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

← →
Гаврила © (2004-08-10 10:13) [13]

> Игорь Шевченко © (10.08.04 10:09) [10]

а зачем лишний код ?
через implements вроде как лишенго кода писать и не надо

← →
Anatoly Podgoretsky © (2004-08-10 10:14) [14]

han_malign © (10.08.04 10:12) [12]
Аггрегация и наследования разные вещи, аггрегация поддержана полностью.

← →
Игорь Шевченко © (2004-08-10 10:20) [15]

> через implements вроде как лишенго кода писать и не надо

? это как, не соображу с утра :)

← →
Rule © (2004-08-10 10:23) [16]

Во спасибо просветили, а почему Борланд не реализовала эту функцию в своем компиляторе,
а интересно в Билдере тогда получается что есть, почему тогад в Делфи не реализовали
может им письмо написать по этому поводу

← →
Думкин © (2004-08-10 10:25) [17]

> [16] Rule © (10.08.04 10:23)

А также по шаблонам, двухпроходности и т.д. и т.п?

← →
REA © (2004-08-10 10:26) [18]

В ООН лучше написать. И лично Нельсону Манделе.

← →
Rule © (2004-08-10 10:29) [19]

REA © (10.08.04 10:26) [18]

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

и я думаю пробемма решится :)

← →
Romkin © (2004-08-10 10:31) [20]

Игорь Шевченко © (10.08.04 10:20) [15] implements - это для интерфейсов :))
Rule © (10.08.04 10:23) [16] Нет. И не надо :)

← →
Игорь Шевченко © (2004-08-10 10:37) [21]

Romkin © (10.08.04 10:31) [20]

> implements - это для интерфейсов :))

На таком уровне я знаю :)
Но не соображу, как можно указанием implements избавиться от написания кода для создания подобия множественного наследования. Где будет реализация методов интерфейса ?

← →
Skyle © (2004-08-10 10:47) [22]

> Anatoly Podgoretsky © (10.08.04 10:14) [14]
> Аггрегация и наследования разные вещи, аггрегация поддержана
> полностью.

А что значит "аггрегация"?
Это что-то типа этого?

TSomeClass = class(...) FSomeField : TSomeAnotherClass;
То есть, объектные поля в классах?

P.S. Подозреваю, что терминология страдает, так что если я неправ, скажите хоть, как это правильно называется...;-)

← →
Иван Шихалев © (2004-08-10 10:54) [23]

> Но не соображу, как можно указанием implements избавиться
> от написания кода для создания подобия множественного наследования.
> Где будет реализация методов интерфейса ?

type I1 = interface ...... end; I2 = interface ...... end; C1 = class(TInterfacedObject,I1) ... реализуем I1 ... end; C2 = class(TInterfacedObject,I2) ... реализуем I2 ... end; CM = class(C1,I2) ..... property P2 : C2 implements I2 ..... end; </cide> CM унаследовал реализацию I1 от C1 и делегировал реализацию I2 к C2. Сам он уже не должен что-либо реализовывать. Правда в конструкторе, наверное, придется создавать экземпляр C2 в какое-то свое поле...

← →
Иван Шихалев © (2004-08-10 10:55) [24]

Назвается - реализация делегированием :)

← →
Гаврила © (2004-08-10 10:57) [25]

> Игорь Шевченко © (10.08.04 10:37) [21]

class1 реализует interface1
class2 реализует interface1 и interface2

экземпляр class1 является полем class2
class2 реализует interface2 сам, а interface1 перенаправлением вызовов на class1 с помощью implements, то есть без кода реализации

← →
Гаврила © (2004-08-10 11:00) [26]

А вообще по поводу множественного наследования есть хороший пример из жизни.
Если потомок наследует все свойства обоих родителей, то у ребенка (человека) должны быть и мужские и женские половые признаки :-))

← →
DiamondShark © (2004-08-10 11:07) [27]

> Игорь Шевченко © (10.08.04 10:37) [21]
> Но не соображу, как можно указанием implements избавиться
> от написания кода для создания подобия множественного наследования.

А что, множественное наследование уже избавляет от написания кода?

> Где будет реализация методов интерфейса ?

В агрегируемом объекте.

Вообще-то, реализация интерфейсов -- более прозрачная и логичная схема, чем множественное наследование.

Кстати, можно пример задачи, где без множественного наследования плохо живётся?

← →
Romkin © (2004-08-10 11:25) [28]

Да, интерфейсы - второй этап ООП, устраняются многие неясности.
А без множественного наследования нормально живется :))
Кстати, в D6 TComponent уже реализует интерфейс. Только недавно узнал :(

← →
Гаврила © (2004-08-10 11:30) [29]

> Кстати, можно пример задачи, где без множественного наследования
> плохо живётся?

Некоторые компоненты (потомки TControl) также имеют машинку UNDO. Для "двух стрелочек" в панели кнопок. По обработке метода Undo так же существует иерархия классов

← →
Игорь Шевченко © (2004-08-10 11:35) [30]

Romkin © (10.08.04 11:25) [28]

> Кстати, в D6 TComponent уже реализует интерфейс. Только
> недавно узнал :(

В D5 тоже.

DiamondShark © (10.08.04 11:07) [27]

> А что, множественное наследование уже избавляет от написания
> кода?

Я не писал - избавляет.

> Вообще-то, реализация интерфейсов -- более прозрачная и
> логичная схема, чем множественное наследование.

Множественное наследование не менее прозрачно и логично.

> Кстати, можно пример задачи, где без множественного наследования
> плохо живётся?

Скажем, иерархия классов, умеющая сохраняться и восстанавливаться из потока. (Для примера - реализация Turbo Vision в Borland C++)

← →
DiamondShark © (2004-08-10 11:48) [31]

> Скажем, иерархия классов, умеющая сохраняться и восстанавливаться
> из потока. (Для примера - реализация Turbo Vision в Borland
> C++)

Мимо! Это как раз и была эмуляция интерфейсов.
Собственно, все примеры с МН, которые я видел, представляют собой именно такую эмуляцию.

Так что фтопку.

← →
Romkin © (2004-08-10 12:01) [32]

Игорь Шевченко © (10.08.04 11:35) [30] в D5 это не так явно :))
Впрочем, наворотили то еще...
И вообще, множественное наследование классов устарело :)

← →
Rule © (2004-08-10 12:06) [33]

Romkin © (10.08.04 12:01) [32]

И вообще, множественное наследование классов устарело :)

Ха, вот этим и буду аргументировать свои доводы по поводу того что оно не надо и можно без этого обойтись

← →
Игорь Шевченко © (2004-08-10 12:07) [34]

Romkin © (10.08.04 12:01) [32]

> И вообще, множественное наследование классов устарело :)

Мода прошла ? :)

Я не совсем понимаю термина "устарел" применительно к наследованию.

← →
Гаврила © (2004-08-10 12:15) [35]

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

← →
имя (2004-08-10 12:19) [36]

Удалено модератором

← →
Игорь Шевченко © (2004-08-10 12:21) [37]

Гаврила © (10.08.04 10:57) [25]

> class1 реализует interface1
> class2 реализует interface1 и interface2
>
> экземпляр class1 является полем class2
> class2 реализует interface2 сам, а interface1 перенаправлением
> вызовов на class1 с помощью implements, то есть без кода
> реализации

Но при этом придется создавать экземпляр class1, передавать ему ссылку на экземпляр class2 (чтобы методы, реализованные в class1 знали о данных class2), правильно ?

← →
Romkin © (2004-08-10 12:24) [38]

Игорь Шевченко © (10.08.04 12:07) [34] Применительно к множественному наследованию классов ;)
Просто наследование никто не отменяет. А устарело потому, что на смену ему пришло наследование интерфейсов.
Простой пример: у предка есть виртуальный метод, наследник его перекрывает, но не вызывает в нем inherited, собственно метод предка. Допустимо ли это технологией? Конечно. Но ведь потомок не знает, что делает метод предка, который он не вызвал. А он может делать что-то, затрагивающее функциональность предка, да хоть количество его вызовов подсчитывать :) Вот и получается, что программист, написав потомок, вторгся в логику работы предка, и изменил ее!
Понятно, есть соглашения, что надо, что не надо... Но это - соглашения. И как правило, приходится смотреть код предка, когда пишешь потомка.
А при использовании интерфейсов таких тонкостей просто нет. И более того, с интерфейсами для того, чтобы твой класс воспринимался как предок, ты не обязан порождать свой класс от предка, можно просто реализовать его интерфейс. Так, как хочется.
А если еще учесть, что при использовании интерфейсов есть возможность агрегировать в себя (читай - унаследовать) всю функциональность класса, написанного на другом языке, то становиться понятным, почему я говорю, что множественное наследование классов устарело :))

← →
Romkin © (2004-08-10 12:30) [39]

Игорь Шевченко © (10.08.04 12:21) [37] Немного не так. Создавать придется. Но перенаправлять ничего не надо, все, что нужно агрегату, это IUnknown class2. А это предусмотрено, см CoCreateInstance, параметр pUnkOuter :))
То есть, агрегирование - это несколько строк кода, объявить и создать, сообщив ему, что он - агрегирован. Указывать надо по той причине, что при агрегации будет использоваться счетчик ссылок контейнера, а не агрегируемого объекта. Остальное - полностью без изменений.

← →
Гаврила © (2004-08-10 12:31) [40]

> Игорь Шевченко © (10.08.04 12:21) [37]

Создать class1 надо конечно, поскольку он является полем class2, то и создать его логично в конструкторе class2. Вот и весь код. НУ а передавать ли ему ссылку на class1 - от задачи зависит :-)

← →
Игорь Шевченко © (2004-08-10 12:33) [41]

Romkin © (10.08.04 12:24) [38]

> А если еще учесть, что при использовании интерфейсов есть
> возможность агрегировать в себя (читай - унаследовать) всю
> функциональность класса, написанного на другом языке, то
> становиться понятным, почему я говорю, что множественное
> наследование классов устарело :))

Множественность-то здесь причем ? Вся эта фраза точно также относится и к одиночному наследованию.

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

Дублируя код предка, если требуется его функциональность ? :))

> Простой пример: у предка есть виртуальный метод, наследник
> его перекрывает, но не вызывает в нем inherited, собственно
> метод предка. Допустимо ли это технологией? Конечно. Но
> ведь потомок не знает, что делает метод предка, который
> он не вызвал. А он может делать что-то, затрагивающее функциональность
> предка, да хоть количество его вызовов подсчитывать :) Вот
> и получается, что программист, написав потомок, вторгся
> в логику работы предка, и изменил ее!

Опять же, причем тут именно множественное наследование ? Все это точно так же может быть отнесено к одиночному наследованию, однако его, почему-то ничкто не отменяет и не пишет, что оно устарело :))

← →
Игорь Шевченко © (2004-08-10 12:34) [42]

Romkin © (10.08.04 12:30) [39]

> Создавать придется. Но перенаправлять ничего не надо, все,
> что нужно агрегату, это IUnknown class2. А это предусмотрено,
> см CoCreateInstance, параметр pUnkOuter

Я вообще-то не про COM...Я вообще-то про обычное использование интерфейсов и наследование...Я в COM не так силен, как ты :)

← →
DiamondShark © (2004-08-10 12:35) [43]

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

← →
Игорь Шевченко © (2004-08-10 12:36) [44]

Гаврила © (10.08.04 12:31) [40]

> Создать class1 надо конечно, поскольку он является полем
> class2, то и создать его логично в конструкторе class2.
> Вот и весь код. НУ а передавать ли ему ссылку на class1
> - от задачи зависит :-)

Только вот я не совсем понимаю, чем это лучше, чем множественное наследование ? :)

← →
Гаврила © (2004-08-10 12:39) [45]

> Игорь Шевченко © (10.08.04 12:36) [44]

Да это и не лучше, просто нет его, множественного наследования у нас :-)

← →
Romkin © (2004-08-10 12:40) [46]

Игорь Шевченко © (10.08.04 12:33) [41] При том, что оно становиться не нужным :)))
А одиночное - можно обойтись и без него, но оно удобно. А главное - достаточно.
>Дублируя код предка, если требуется его функциональность ? :))
Вот именно. Ты можешь унаследовать предка, можешь его агрегировать, а можешь продублировать его фукнциональность :)
На выбор. И при этом пользователь твоего потомка просто не догадается, как именно ты сделал :)))
Более того, пользователь часто вообще не знает, как и где именно реализован данный интерфейс ;)

← →
Игорь Шевченко © (2004-08-10 13:08) [47]

DiamondShark © (10.08.04 12:35) [43]

> Наследование -- инструмент повторного использования кода.

Игорь Шевченко © (10.08.04 10:09) [10]

> Мне, например, из-за его отсутствия приходится писать лишний > код. Иногда напрягает

:)

Romkin © (10.08.04 12:40) [46]

> А одиночное - можно обойтись и без него, но оно удобно.
> А главное - достаточно.

Честно говоря, не понимаю :)

> Вот именно. Ты можешь унаследовать предка, можешь его агрегировать,
> а можешь продублировать его фукнциональность :)

Собственно говоря, введение множественного наследования не мешает мне сделать те же три действия :)

> Более того, пользователь часто вообще не знает, как и где
> именно реализован данный интерфейс

Какой пользователь имеется в виду ?

← →
Антон (2004-08-10 13:16) [48]

Я вообще-то в Delphi не секу, пишу на С++, а этот форум зинтересовал меня по простой причине, хочу понять, есть ли объективые причины почему в Delphi не реализовано множественное наследование. Я исключаю ответы типа устарело, излишне, приводит к ошибкам. Основной вопрос - может ли это быть связано с различием в процессах распеделения памяти и т.п.

А вообще множественное наследование легко реализуется простым вложением двух объектов различных классов в качестве членов третьего, далее остается только предоставить код, возвращающий адреса этих объетов. Так например:

class A { }; class B { }; class C : public A, public B { }; экивалентно class C { A a; B b; }

← →
Игорь Шевченко © (2004-08-10 13:22) [49]

> А вообще множественное наследование легко реализуется простым
> вложением двух объектов различных классов в качестве членов
> третьего, далее остается только предоставить код, возвращающий
> адреса этих объетов. Так например:
>
>
> class A { };
> class B { };
>
> class C : public A, public B { };
> экивалентно
> class C { A a; B b; }

Не эквивалентно. Класс C не может быть представлен ни как класс A, ни как класс B

← →
Антон (2004-08-10 13:29) [50]

Хорошо, продолжу:
struct A {}; struct B {}; struct C { A a; B b; operator A* () { return &a; } operator B* () { return &b; } }; void f() { C c; A* p_a = c; B* p_b = c; cout << p_a << " " << p_b << " " << &c << endl; }
В результате видим примерно следующее:
0012FF74 0012FF78 0012FF74
Это аблолютная аналогия.

← →
Игорь Шевченко © (2004-08-10 13:46) [51]

> В результате видим примерно следующее:
> 0012FF74 0012FF78 0012FF74
> Это аблолютная аналогия.

???????????????????? Эт как ?

← →
Piter © (2004-08-10 13:57) [52]

Игорь Шевченко © (10.08.04 10:09) [10]
Мне, например, из-за его отсутствия приходится писать лишний код. Иногда напрягает

а можно пример, когда множественное наследование полезно?

← →
Антон (2004-08-10 13:58) [53]

> ???????????????????? Эт как ?
Аналогичный результат я получу если просто напишу класс С при помощи синтаксиса множественного наследования, как показывал выше. Дело в том, что память распределится идентичным образом в обоих случаяю, поэтому разницы никакой нет.

← →
Антон (2004-08-10 14:02) [54]

> а можно пример, когда множественное наследование полезно?

Есть такой мультик - КОТОПЕС, а если серъезно, то любое моделирование гибридных объектов.

← →
Piter © (2004-08-10 14:46) [55]

Антон (10.08.04 14:02) [54]

нет, мне бы пример. Например, постановка задачи и путь ее реализации. Желательно в терминах Delphi

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

← →
DiamondShark © (2004-08-10 14:51) [56]

> то любое моделирование гибридных объектов.

Агрегирование.

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

Это зависит от конкретной реализации языка, не так ли ?
Синтаксис наследования является стандартом языка, в то время, как распределение памяти стандартом отнюдь не является.

← →
Антон (2004-08-10 15:43) [58]

> Это зависит от конкретной реализации языка, не так ли ?
> Синтаксис наследования является стандартом языка, в то время,
> как распределение памяти стандартом отнюдь не является.

Вот это меня и интерисует, я как абсолютный профан в Delphi, не знаю можно ли аналогично реализовать множественное наследование посредством агрегации, как я показал на примере с С++. Это был пример для обсуждения и не больше. Что мешает реализовать аналогично множественное наследование в Delphi, вот в чем вопрос? Ведь у вас есть простое наследование, нет операторов преобразования типа как в С++, но их можно заменить и на обычные ф-ии члены класса (воспрос синтаксиса)?

← →
Антон (2004-08-10 15:50) [59]

> нет, мне бы пример. Например, постановка задачи и путь ее
> реализации. Желательно в терминах Delphi
>
> Например, нечто реализовывается так. Но вот если было бы
> множественное наследование - то это можно было бы реализовать
> гораздо проще, потому что...

Прости, в терминах Delphi не могу, просто не знаю, да и дело не в терминах. Я могу привести пример реализации библиотеки Motif. Она не относится к вопросу о множественном наследовании. Но она эмулирует C++ в части скрытия данных и разграничения доступа, хотя это чисто С библиотека. Можно использовать средства языка для эмуляции средств не реализованных в языке, но проще пользоваться синтаксисом заложенным изначально в язык, по моему это удобнее.

> Вот это меня и интерисует, я как абсолютный профан в Delphi,
> не знаю можно ли аналогично реализовать множественное наследование
> посредством агрегации, как я показал на примере с С++.

Я имел в виду, что в различных реализациях одного языка (С++) реализация может быть разная.

← →
Антон (2004-08-10 16:09) [61]

> Я имел в виду, что в различных реализациях одного языка
> (С++) реализация может быть разная.

Понял твой намек. Дело в том что модесь COM, которая упоминалась в форуме реализуется именно с помощью агрегации, спорить с этим бесполезно. Так на чем же она основывается? Ответ очевиден. Что-бы предоставить доступ к интерфейсу, не использую конструкции C++, приходится эмулировать его с помощью агрегации...

Вот пример. Есть библиотека где представлены различные классы (со своей иерархией наследования), в том чсле TSomeClass. Допустим, эту библиотеку мы изменять не можем. В определенный момент равития системы (пишется компонет, имеюший published свойство типа TSomeClass). Нам надо чтобы этот класс был порожден от TPersistent и умел сохраняться в поток, присваиваться и т. д.

← →
Антон (2004-08-10 16:28) [63]

> Я имел в виду, что в различных реализациях одного языка
> (С++) реализация может быть разная.

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

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

Однопроходность здесь ни с какого боку, вроде...

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

2 Mystic © (10.08.04 16:18) [62]
Минуточку - тут имеет место небольшое лукавство:
Если это компонент (для формы/ДатаМодуля) - он уже наследуется от TPersistent - и это упрощает дело
Если же это просто класс - то это уже не проблема вызвать у него метод SaveToStream самому (на мой взгляд).

> Если же это просто класс - то это уже не проблема вызвать
> у него метод SaveToStream самому (на мой взгляд).

А если его нету ?

← →
Антон (2004-08-10 17:17) [67]

> > Если же это просто класс - то это уже не проблема вызвать
> > у него метод SaveToStream самому (на мой взгляд).
> А если его нету ?

Причем метод которого нету, можно конечно реализовывать "ЖИРНЫЙ" интерфейс, который предусматривает чисто фиртуальные метомы (в вашем понимании интерфейсы), обеспечивая совместимость на уровне вызова ф-ий членов, но для чего? Елсли нет возможности преобразовать тип во время исполнения в производный, только тогда возможен изврат с ЖИНЫМ интерфейсом (а как на счет производных классов которые в приципе не могут реализовать данный интерфейс..., что делать заглушки...?)

Хм..
Есть класс (TParent1), который изменять нельзя. Порождён не от TMyClass1.
Надо: Добавить ему функционал этого TParent2.

Решение 1: Без использования множественного наследования
Добавляем в новый класс(TChild) поле типа TParent2. Устанавливаем его свойства, обработчики и т.п. Везде, где надо, суём поле, а не сам класс (TChild).
+ Хорошо, если этот функционал не должен затрагивать функционал и поля TParent1.
- Плохо, если необходимо чтобы новый функционал работал с полями исходного класса TParent1 как со своими собственными

Решение 2: С использованием множественного наследования
Добавляем в новый класс(TChild) родителя типа TParent2. У него появляются новые поля и методы для исполнения соответствующего функционала.

Вопрос - как TParent2 должен взаимодействовать с Методами и Полями другого TParent1 в TChild?

Я как-то пока себе не представляю.

Ещё - если функционал TParent2 должен работать с полями TParent1, то в TChild надо переписывать эти методы.

Выигрыш - TChild на вопрос is TParent1 ответит True, и позволит работать с классом, как с TParent1.

P.S.
Cobalt © (10.08.04 17:52) [68]
Следует читать:
Есть класс (TParent1), который изменять нельзя. Порождён не от TParent2.
Надо: Добавить ему функционал этого TParent2.

Бррр. Ну что вы маетесь?! Я вообще уже ничего не понимаю.
В Delphi нет множественного наследования классов. Оно не обязательно.
Но если очень хочется - есть множественное наследование интерфейсов, и пользоваться им гораздо приятнее :)
Например, можно создать потомка на Delphi от класса, написанного на С++ Ж-)

просто меня тоже заинтересовало - были ли какие-то объективные причины для того, что бы не реализовывать множественное наследование в Delphi? Или просто решили, мол, нафиг это не надо, не будем с этим заморачиваться, и вообще это непопулярно, и забили на этом жирный крест.

Естественно, просто решили.
Надо будет - введут. Но лучше не надо :)

Отчего же?
Довольно-таки удобно, компилятор будет ругаться на вызов метода без указания его родителя (при наличии нескольких одноимённых у разных предков), все будут довольны :)

← →
Бином Ньютоныч (2004-08-10 19:54) [75]

Причины, имхо, вполне конкретые. Множ. наследование - бред бушевноболдьного. Два - три этапа - и в эторм классе сам черт со страуртруппом не разберутся, не говоря уж про нас, бедных...:(

← →
Бином Ньютоныч (2004-08-10 19:57) [76]

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

2 Бином Ньютоныч (10.08.04 19:54) [75]
Ну, не скажите. Если программист запутался втом, что же делает (может делать) его класс - это его проблема. при строгом непересекающемся наследовании я не вижу проблем составить карту методов и полей, унаследованных от всех его родителей.

Единственная проблема, которую я углядел - конфликт Published-свойств у компонентов - как их отображать? сохранить в dfm?
Загружать из dfm? Вот это, кажется - самое трудное - пришлось бы, наверное, добавлять в RTTI данные о классах и их Published-свойствах - для того, что бы можно было выбирать. Типа
GetParentClass(Parent1Name).SetProperty(PropertyName1).AsString

P.S. Я пробовал смотреть исходники TReader, но, честно говоря, не понял - где же он устанавливает значение Published-свойств?

← →
Бином Ньютоныч (2004-08-10 21:32) [78]

>Cobalt © (10.08.04 20:56) [77]

Извините, но большая часть Вашей работы - это использование чуого кода(VCL) И это здорово, я не против:)

Да нет, Вы просто попробуйте построить иерархию со множественным наследованием. Ничего сложного не используйте, все обыденно: источник данных, обраьотчик коллизий, интерфейс юзера... Потом сделайте еще шаг - администратор. Потом Вам(юзеру) захочется быть супервизором. А кому не хочется - всем хочется. Но мы не позволим, мы умные, видали уже. Однако заказчик настаивает. Ладно, Вы обговорили бабки, но слабина уже есть! Он захочет большего, причем в рамках. Откажешь? Дудки, это же клиент, деньги, жизнь... А дальше? Ну сколько ты будещь расширять функ. в рамках языка? А когда выйдет за рамки? Но это все хрень. Что мне ДЕЙСТВИТЕЛЬНО непонятно - как ты будешь обеспечивать БЕЗОПАСНОСТЬ всей этой хрени? Поделись:)

Я чувствую, ты что-то хочешь сказать мне, что-то наболевшее...
Но вот что - я никак не пойму.

Может, ещё какие есть объективные причины для отсутствия множественного наследования?

Вот спорю с коллегой на работе, подскажите есть ли множественное Найти похожие ветки