aggregate() in PHP5

[Hubbitus]

Вобщем изначально проблема в том что меня очень сильно угнетает отсутствие множественного наследования (multiple inheritance) в PHP.

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

PHP код:

Call to undefined function aggregate() in..... 


PHP 5.0.4, Линукс.

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

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

Ну И (или) дополнительный вопрос: Какими еще путями можно сделать аналог множественного наследования? Пожалуйста с короткими (пару строк) описаниями плюсов/минусов/ограничений и желательно где можно про это подробнее почитать, посмотреть примеры (или свои, если есть).

Заранее всем благодарен.

[Saruman]

Имхо, прикручивать к языку то, что в нем концептуально не поддерживается - зло и прямой путь к самоубийству. Но это, ессно, мое пуристское имхо 8))
А если по теме - то, думаю, стоит обратить внимание на интерфейсы и подумать, а на самом ли деле тебе так уж нужно множественное наследование (или, может, просто стоить изменить дизайн и устранить необходимость в нем?).
Multiple Inheritance and Interfaces
OOL basics - Use interfaces for safe multiple inheritance and a great deal more

[knight]

А нужно ли в задаче использовать множественное наследование ? Ведь априори без него можно почти всегда обойтись. Либо же интерфейсы путь к решению проблемы. Например в том же C# наследование поддерживается множественное только от интерфейсов. Безусловно это только моё мнение

[Hubbitus]

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

А чего я к нему прикручиваю? Агрегация была в PHP4 и я хотел ее заюзать, что тут такого страшного вдруг???

Saruman:
А если по теме - то, думаю, стоит обратить внимание на интерфейсы

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

Saruman:
а на самом ли деле тебе так уж нужно множественное наследование (или, может, просто стоить изменить дизайн и устранить необходимость в нем?).

Гыг, ну конечно же, Saruman, ты меня и просветлил конечно я всю логику могу и на ассемблере написать! Только вот оно надо??? Конечно я до сих пор обходился без множественного наследования, но очень хочется иметь в руках такой мощьный и главное удобный инструмент - в той же Java это почему-то есть очень давно, и никто не плачет что это лишнее или все программисты на ней дебилы...

knight, на твое поддакивание позволь не отвечать, все в той же мере что ответил Выше )

А по указанным ссылкам про Java и С++ а не про PHP, я знаю что в них разрешено множественное наследование, вот этого же я и хочу.

[Saruman]

Hubbitus:
ты меня и просветлил конечно

Нафиг надо

Hubbitus:
в той же Java это почему-то есть очень давно

Мдя? Средствами языка? Ну давай, наследуй 8)))
Multiple inheritance in Java

Java was designed without multiple inheritance. While some developers think of this as a flaw, it is actually true that the overall design of Java supports the solution of problems commonly solved with multiple inheritance in other ways. In particular, the singly rooted hierarchy (with Object as the ultimate ancestor of all classes) and Java interfaces solves most problems that are commonly solved using multiple inheritance in C++.

Hubbitus:
А по указанным ссылкам про Java и С++ а не про PHP, я знаю что в них разрешено множественное наследование, вот этого же я и хочу.

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

PS: возвращаясь же к твоей aggregate():
PHP: aggregate - Manual

A note for those who may be implementing projects in PHP4 using aggregate(); these functions do not exist in PHP5. For similar functionality, you can try using the Classkit extension:

http://us2.php.net/manual/en/ref.classkit.php

[Hubbitus]

Прошу прощения, про Java'у я конечно же ошибся.
Но это нормально поддерживают C++ и JavaScript

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

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

"Interfaces don't just provide a workaround to Java's lack of support
for multiple implementation inheritance."

This just isn't true, to me. They aren't a workaround. Without
inheriting functionality (implementation), they are a completely
different animal, providing only syntactic inheritance, as stated in the
next sentence:

"Interfaces factor out commonality across diverse class hierarchies,
resulting in compact and understandable source code."

It's all about the source code, not the functionality, to put it
bluntly.

А вот за ссылку на класскит спасибо, хоть что-то дельное!! Буду читать.

P.S. Почему вместо ответа на вопрос чаще всего начинают с того что этого автору совсем не нужно делать, вместо помощи КАК это сделать? Ну или уж хотябы предложения как это сделать альтернативным способом...

[Saruman]

Hubbitus:
Почему вместо ответа на вопрос чаще всего начинают с того что этого автору совсем не нужно делать, вместо помощи КАК это сделать? Ну или уж хотябы предложения как это сделать альтернативным способом...

Хм. Было:

Hubbitus:
Какими еще путями можно сделать аналог множественного наследования?

Имхо, в данном случае самый правильный путь - изменить дизайн приложения так, чтобы избавиться он необходимости использования МН, что я и попытался высказать в надежде на последующее конструктивное обсуждение. Но нет - так нет. В любом случае, рад был помочь 8)

[Hubbitus]

Saruman:
Имхо, в данном случае самый правильный путь - изменить дизайн приложения так, чтобы избавиться он необходимости использования МН

MI полагаю имелось ввиду? Да это даже не то чтобы необходимость его использования, просто хочется комфортного программирования, с произвольным логическим разбиеним кода на составляющие, и соответственно его потом простой и удобной сборки воедино. Естественно писал и пишу, обходился и сейчас обхожусь без этого, но было бы гораздо удобнее с подобной технологией. Тем более, чем больше смотрю, тем более убеждаюсь что многим это интересно, и многие предлагают различные пути подобной реализации, (а не только "не нужно это" кричат), поэтому тоже собираюсь посмотреть, почитать... возможно что-то и найду, удобное мне...
Saruman, а вот ты говоришь, ты можешь привести реальные доводы чем множественное наследование плохо так уж? Почему на него никто не жалуется в JavaScript и С++, но повсеместно кричат что это лишнее в PHP???

[Saruman]

Hubbitus:
MI полагаю имелось ввиду

Угум, просто по-русски.

Hubbitus:
реальные доводы чем множественное наследование плохо так уж

Классический пример - diamond inheritance, оно же diamond-of-death. Вкратце - класс A наследует от двух классов B и C, которые, в свою очередь, имеют общий суперкласс D. Если классы B и C переопределяют один и тот же метод, то чья имплементация должна использоваться в A?

повсеместно кричат что это лишнее в PHP

Заметь, я нигде не говорил, что ты ни в коем случае никогда не должен его использовать. Если ты уверен в его необходимости - пожалуйста. Я не имею представления о твоем дизайне, что и зачем тебе в нем нужно наследовать, я высказываю свои общие соображения, которые сводятся к тому, что в 99% случаях лучше использовать composition/delegation, а не MI. В конце-концов, коллизии а-ля diamond-of-death ты можешь получить не сразу, а много позже, добавляя некую функциональность в свои базовые классы, и не факт, что после ее обнаружения рефакторинг для решения проблем будет тривиально простым. Посему - do the simplest thing that could possibly work, и MI в мое понимание данной концепции в большинстве случаев никак не вписывается.
Если хочешь конкретики - то дизайн в студию и будем уже тыкать пальцами и рассуждать о конкретных решениях. Существует вероятность, что я и признаю твою правоту в данном конкретном случае.

[knight]

Hubbitus:
knight, на твое поддакивание позволь не отвечать, все в той же мере что ответил Выше )

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

[Saruman]

Кста, дописывая очередной тест, понял еще один недостаток MI и преимущество композиции. Если исходить из того, что тестами должен быть покрыт весь код (что логично, т.к. если суперкласс проходит набор тестов, это еще не значит, что аналогичные тесты будут 100% проходит и в субклассе), то при написании юнит теста для субкласса мы должны также полностью покрыть всю функциональность, наследуемую им от родителей. При этом, если дальнейшие изменения в суперклассах нарушат тесты данного субкласса, то не очевидно, изменения в каком из них привели к этому, т.к. все суперклассы имеют влияние на результаты тестов.
Если же мы использует композицию, то просто заменяем вложенный класс стабом/моком и забываем про изменения в нем. До тех пор, пока интерфейсные методы этого класса проходят тесты на заявленную функциональность, любые изменения в нем не приведут к нарушениям в использующих его классах. Это не считая того, что таким образом мы сокращаем объем необходимых тестов.