вопрос по архитектуре (конфликт доступа конструкторов)

[crocodile2u]

Да, с трейтами такие штуки оч хорошо будут получаться. А если по теме, то наследовать Registry и Session от какого-то Data - плохое решение: они очевидно друг с другом не связаны и не должны быть в одной иерархии наследования - это раз. А два - класса Data вообще не должно быть - это как класс Object, который постоянно появляется в коленочно-самописных ЦМСках. И это явный пример антипаттерна God-object, который с какого-то хрена почему-то знает, что нужно всем его многочисленным потомкам (явно, так сказать, от разных матерей).

 

[Духовность™]

не должны быть в одной иерархии наследования - это раз

не должны, но копипастить код не хочется/

это как класс Object, который постоянно появляется в коленочно-самописных ЦМСках

от того видно и появляется, что нужен часто. А идея класса Data на самом деле простая - объектный НОРМАЛЬНЫЙ массив. Как во всех нормальных языках программирования.

 

[crocodile2u]

Как во всех нормальных языках программирования

Ишь Почему бы тогда не писать на нормальных языках?

от того видно и появляется, что нужен часто

"Скрипач не нужен" (с) Кин-Дза-Дза

 

[Krishna]

Есть класс Registry и Session, которые должны быть унаследованы от класса Data

Заменить наследование делегированием или реализацией общего интерфейса.
Всё остальное, имхо, будет костылями.

 

[AmdY]

triumvirat
есть одно простое правило "если получается сложно - значит это не правильно". выбрось реестр, выбрось статические методы - они нелогичны, всё что не передаётся явно в конструктор или нельзя получить методом $this->get<Объект>() - всё вон, это неявно и плохо. пожалей коллег, которые будут писать код, пожалей свою память.

 

[craz]

AmdY
+1

 

[Духовность™]

всё что не передаётся явно в конструктор или нельзя получить методом $this->get<Объект>() - всё вон, это неявно и плохо

где прикажете хранить мелкие настройки программы- пути, соль, email-адреса роботов и т.д.? В глобальной области видимости?

И почему такое утверждение? Вон, livestreet так хранит настройки: Config::Get('path.root.server')

Чем это хуже чем через Registry::getInstance()->path['root']['server'] ?

Заменить наследование делегированием

как это, поясни на примере.

 

[Krishna]

как это, поясни на примере

Присвоить свойству "предка" ссылку на объект "родитель". И тупо переадресовывать вызовы "предку".

-~{}~ 08.09.10 02:08:

http://ru.wikipedia.org/wiki/Шаблон_делегирования

 

[fixxxer]

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

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

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

Тут traits очень в тему. Надеюсь, что trait может реализовывать интерфейс без побочных эффектов (да, я ленивая сволочь и еще не собирал из транка и не тестил, просто рассуждаю вслух, но - как то уже привык, что в php часто выходит "как всегда"...).

 

[Adelf]

В общем fixxxer меня убедил Я вот только не понял каковы перспективы у traits? Сейчас оно существует как отдельный пропатченный php... Есть какие-либо надежды?

 

[AmdY]

Adelf
он в транке

 

[fixxxer]

http://snaps.php.net/

 

[A1x]

он в транке

что это значит? какая перспектива что появится в релизе?

 

[fixxxer]

Это значит, что оно появится в следующем крупном релизе (5.4), если не передумают (то есть, не вылезет что-то страшное, что все ломает).

Шансы на появление в 5.3.х примерно нулевые - так как добавлено зарезервированное слово (и сломаются скрипты, которые, например, содержат функцию trait).