У Laravel намного более вменяемая документация, чем у Yii, и с учётом полноценного ООП, особых вопросам там не возникает. Мне просто не нравится, что разработчики Yii продолжают пиарить его не взирая на то, что первая версия морально жутко усторела(я уже молчу про поколение быдлкодеров выращенных на ней), и не смотря на то что вторую версию уже который год не могут выпустить(тут дело либо в лени, либо в неппрофессионализме, либо во внутренних противоречиях в сообществе/команде).
Короче, я считаю то что сейчас представляет из себя Yii как продукт в сравнении с прочими фреймворками - не достойно пиара. Разработчикам лучше заняться выпуском релиза второй версии, а не бегать по всяким тостерам и рекомендовать всем подряд своего шизоидального пенсионера Yii первой версии.
Yii подходит, а Laravel нет? Есть огромное фреймворков, которые по скорости ничуть не уступают Yii. Честно говоря надоело, что в рунете Yii так доминирует, с его отвратительной архитектурой в первой версии, и вечной беты второй. Заметил такую закономерность: чем выше классом программист - тем больше он поносит Yii. Не с проста.
Ну т.е. тот же вариант, что я в описании вопроса привёл? У него есть один большой минус: спецификация класса не подразумевает обязательность вызова init перед вызовом getInstance(
Даже не представлю как будет выглядеть реализация Immutable на PHP..( А Multiton очень похож на тот код, что я привёл в примере, только у них __construct вместо ::init() и getInstance() параметризован какого-то хрена)
В том то и дело, что никакого такого SingletonConfiguration класса для хранения динамических параметров инициализации нет и быть не может т.к. мы не можем гарантировать существования инстанса этого класса на момент вызова Singleton::getInstance
Блин, ну это уже в какой-то холивар переходит… Какой смысл запрещать изменять объект, если программист всегда сможет создать ещё один? Что плохого в том, чтобы явным образом ограничить программиста в инициализации более чем одного инстанса класса, если это действительно необходимо? Если программист будет использовать костыль типа unesrialize(serialize($instance)) чтобы обойти эту унификацию, то значит берёт на себя ответственность за все возможные последствия.
1. Ваше решение введёт в заблуждение программиста, если он повторно вызовет getInstance с другими параметрами
2. Registry не гарантирует уникальность инстанса класса.
Зачем? Тогда начётся холивар на тему насколько мне актуальна его уникальность :) Мне нужно хоть какое-то решение в рамках озвученной задачи, пусть даже такое плохое как stackoverflow.com/a/11081838/341260
и в последнем случае не узнает о том, что его $params2 никак не повлияют на результат. Т.е. тут вы скрещиваете понятие синглотона и фабрики, что само по себе очень противоречиво.
Я не спорю с мануалом, мне бы решение проблемы найти в рамках оговоренных условий.
То что вы тут пересказываете я и так знаю, а по поводу группировки pconnect по хосту-юзеру — это ок, но я почему-то думал, что для разных mysql_select_db он всё-таки догадается разные соединения создать, а то жесть какая-то получается.
