т.е. сделать то, что и так уже есть в языке — объекты.
ArrayAccess входит в тройку самых ужасных для меня возможнойстей PHP: сразу за магическими __get, __set
и ReflectionProperty::setAccessible().
Код с применением указанных возможностей прекрасный способ усложнить себе и другим разработчикам жизнь.
Благодатная идея объекта, состоящего из произвольных свойств, которые можно создавать и удалять «на лету», как элементы в массиве, приходит в голову каждому программисту на PHP.
Зачем? Пожалуйста, объясните зачем вы это делаете? Откуда в PHP эта «мода» делать из объекта массив?
Автор ( и я его поддерживаю) предлагает использовать именованные конструкторы ( в частной реализации PHP это статические фабричные методы) для объектов доменной области, а в них DI не нужен.
А если уж очень нужно иметь сервис с разными конструкторами ( сложно представить такую ситуацию), то в том же Symfony DI есть поддержка фабрик.
Недавно заменил свои Plantronics Backbeat Go 2 на прекрасные Samsung Gear Circle — доволен как слон. Хорошее звучание, удобно бегать (есть специальные крепления для шеи в комплекте), а идея с магнитом просто великолепна.
Сабж, же интересен с виду, но удобство использования под сомнением: малое время автономной работы, легко потерять, множество ненужных датчиков (ну зачем в наушниках 3-хосный акселерометр и термометр?).
Да, как же уже все надоели с этим методом! Twitter, Facebook заполнены такими «шутками», а теперь и на Хабр просочилось… Никакой логической ошибки тут нет и быть не может т.к. возвращается новый объект, а старый остается без изменений, что является обычной практикой для Value Object к коим относится и DateTimeImmutable.
Советую ознакомиться с презентацией Fabien Potencier (создателя вышеупомянутого Pimple, мэйнтейнера Symfony 2 и CEO Sensio Labs). Мне, в свое время, она очень помогла.
Языковая конструкция new создает экземпляр объекта указанного класса. Вызов конструктора при этом является побочным действием и не влияют (кроме брошенного исключения) на поведение new, и как следствие интерпретатор PHP не учитывает блок возврата (return $something) в конструкторе.
Но вообще, я не силен в ООП, могу и ошибаться.
С этого и стоило бы начать. Для вопросов есть соответствующий сервис.
Получаем чистый, не блокирующий код на PHP без Lua прослойки.
Тогда может и не нужен тут PHP?
А так, никакие прослойки уже давненько не нужны. Есть Ratchet, Aerys и т.д.
Похоже, должно быть так
https://beberlei.de/2013/03/04/doctrine_repositories.html.
PHP начиная с версии 5.3 достаточно хорош, а с приходом 7.х еще лучше.
т.е. сделать то, что и так уже есть в языке — объекты.
ArrayAccess входит в тройку самых ужасных для меня возможнойстей PHP: сразу за магическими __get, __set
и ReflectionProperty::setAccessible().
Код с применением указанных возможностей прекрасный способ усложнить себе и другим разработчикам жизнь.
Зачем? Пожалуйста, объясните зачем вы это делаете? Откуда в PHP эта «мода» делать из объекта массив?
А где в предложенном подходе обращение к приватным полям объекта извне? Все происходит внутри самого объекта и полностью согласуется с ООП.
А если уж очень нужно иметь сервис с разными конструкторами ( сложно представить такую ситуацию), то в том же Symfony DI есть поддержка фабрик.
Раскажите об этом ребятам из Sensio Labs что они на Symfony 2 оказывается плохо зарабатывают.
Сабж, же интересен с виду, но удобство использования под сомнением: малое время автономной работы, легко потерять, множество ненужных датчиков (ну зачем в наушниках 3-хосный акселерометр и термометр?).
Bernhard Schussek — Разработчик Symfony (в частности Symfony Forms). http://webmozarts.com
William DURAND — Разработчик Propel. http://williamdurand.fr
Mathias Verraes — Популярный спикер на Agile и PHP конференциях. http://verraes.net
С этого и стоило бы начать. Для вопросов есть соответствующий сервис.