aggregate() in PHP5
 

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

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

PHP 5.0.4, Линукс. :idontnow:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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