Guzzle не устроил интерфейсом. Есть проект. В нём есть зависимости. Одна зависимость использует Guzzle, вторая — httplug, третья ещё что-то. В итоге у нас натягивается много либ. Если зависимости используют httpclient вместо всего этого, появляется возможность вытаскивать одну либу и собирать только её баги.
p.s. да, PSR-7 сейчас эту проблему решает, но тогда его не было...
Definitive guide не предлагает использовать AR всегда и везде. Наверное, надо добавить ещё больше сносок про то, что это везде и всегда не надо… если есть идеи, куда именно и в какой форме — дайте знать.
Вы хотите, чтобы на PHP были либо опытные продвинутые разработчики, либо никого? Я нет потому что тогда сильным проектам, где эти продвинутые разработчики нужны, будет неоткуда вырастать.
Yii допускает много вольностей. На нём можно быстро фигачить, а можно писать грамотно и хорошо. Зависит от опыта и дисциплины того, кто пишет.
queue — фреймворконезависимых очередей нормальных не нашлось. Запилили прототип на хакатоне потому что было интересно, сможем ли. Прототип Журавлёв допилили до прекрасного состояния и расширение мы приютили. При этом он его развивает, мы только помогаем советами и докой, как и помогали пока репозиторий был в его аккаунте. Времени не кушает.
authclient был с самого начала. Он прилично интегрирован с аутентификацией. Если бы использовали внешнюю либу для OAuth, так и так пришлось бы обёртку делать.
collection — сильно просили прямо в фреймворке сделать поддержку. Решили сделать в расширении. Это не просто generic-коллекции, там есть и специфичные для AR Yii штуки, которые позволяют работать с базой довольно эффективно, а не вытягивать всё и фильтровать средствами PHP.
httpclient — обёртка с двумя простейшими дефолтными драйверами. Нужна чтобы, например, можно было бы подменить Guzzle на что-то ещё.
shell — да, скорее всего так. Но каши не просит, можно и оставить.
Вам выше уже всё сказали — зачем, к примеру, пилить свой, какой-нибудь к примеру FileSystemHelper, если есть множество готовых, устанавливающихся одной командой composer? А на это тратится безумное количество времени.
Конкретно FileSystemHelper — только обратная совместимость. Некоторые другие части Yii, которые есть где-то ещё, потому что они получились лучше, чем где-то ещё.
Ну и плюс тут вопрос контроля и хрупкости. Вспомните left-pad и npm...
Да не, не приходится. Отлично всё конфигурируется либо через контейнер, либо по месту. Просто люди привыкли делать обёртки ещё с 1.1 и по инерции наделали их очень много...
Я тоже. Одно дело сам фреймворк — в него компоненты удачные перекочевали из тех времён, когда ничего не было. Плюс некоторые запилили с нуля потому как было время на них и могли сделать хорошо. Итеративно улучшать это всё логично потому как оно не хуже альтернатив. Хотя, конечно, временами некоторые части хочется выкинуть и взять что-то, что их переросло. Но обратная совместимость в 2.0 это сделать не позволяет.
Совсем другое дело — проекты. Вот в них чем руководствуются, реализуя с нуля всякое, я не уверен...
То, что для ее поддержки пришлось писать свой автолоадер?
Нас, кроме алиасов, интересовала ещё и скорость загрузки классов. На момент релиза Yii лодер Composer-а был совсем плох в этом плане. issue на тему loader-а практически не было, работает всё стабильно, каши не просит.
В итоге теперь мы оперируем и неймспейсами и алиасами. Алиасы для ФС выглядят как вынужденное наследие Yii 1, а не фича.
Алиасами мы для загрузки классов не оперируем. Как и не оперируем неймспейсами для работы с файловой системой.
Выделяя модули/расширения Yii-шного приложения в отдельные пакеты, мы на много лет вперед привязываемся к текущей мажорной версии Yii. Либо вынуждены писать максимально абстрагируясь то Yii, что очень непросто.
Так этот факт не меняется вне зависимости от используемого фреймворка. Писать независимые компоненты сложнее, чем завязанные на другой код.
Будет интересно услышать от вас планы по развитию фреймворка.
Эволюционные. Будем облегчать ядро, избавляться от всяких jQuery, выкидывать версии PHP до 7-ки, выкидывать HHVM. Выпиливать части в расширения и независимые библиотеки, которые, по возможности, будут поддерживаться заинтересованными разработчиками. Облегчать дерево наследования и стремиться выпилить его совсем...
Революции вроде 1.1 → 2.0 не хочется. По крайней мере пока.
Если не секрет, кто сейчас решает стратегические вопросы?
Я, Carsten Brandt, Дмитрий Науменко, Климов Павел, Boudewijn Vahrmeijer.
В Yii вы можете навесить валидатор на соответствующий приватному свойству геттер. А вообще валидировать приватные свойства не в конструкторе и не в сеттере несколько странно.
Guzzle не устроил интерфейсом. Есть проект. В нём есть зависимости. Одна зависимость использует Guzzle, вторая — httplug, третья ещё что-то. В итоге у нас натягивается много либ. Если зависимости используют httpclient вместо всего этого, появляется возможность вытаскивать одну либу и собирать только её баги.
p.s. да, PSR-7 сейчас эту проблему решает, но тогда его не было...
Definitive guide не предлагает использовать AR всегда и везде. Наверное, надо добавить ещё больше сносок про то, что это везде и всегда не надо… если есть идеи, куда именно и в какой форме — дайте знать.
Порог действительно низкий. Это так.
Вы хотите, чтобы на PHP были либо опытные продвинутые разработчики, либо никого? Я нет потому что тогда сильным проектам, где эти продвинутые разработчики нужны, будет неоткуда вырастать.
Yii допускает много вольностей. На нём можно быстро фигачить, а можно писать грамотно и хорошо. Зависит от опыта и дисциплины того, кто пишет.
4 года — это время жизни нормального проекта. Не каждые же пол года ломать всё и релизить мажорную версию...
Можно завести две record на одну таблицу в разных namespace-контекстах.
Из этого ничего :)
Конкретно FileSystemHelper — только обратная совместимость. Некоторые другие части Yii, которые есть где-то ещё, потому что они получились лучше, чем где-то ещё.
Ну и плюс тут вопрос контроля и хрупкости. Вспомните left-pad и npm...
Да не, не приходится. Отлично всё конфигурируется либо через контейнер, либо по месту. Просто люди привыкли делать обёртки ещё с 1.1 и по инерции наделали их очень много...
А сразу писать нормально или порефакторить потом никак?
Инстанциацию кастомную надо, да. Что-то вроде https://github.com/samdark/hydrator
Нет. Ничего не наследуется от AR. Используется либо AR внутри репозитория, либо вообще не используется. Query Builder тоже неплох.
Я много чего не озвучил: https://github.com/yiisoft/yii2/wiki/Plan-for-next-major-versions Плюс посмотрите issue на 2.1.
Так и в Yii можно так же. DI контейнер в фреймворке вполне себе универсальный и может настраивать не только классы самого фреймворка.
Также посмотрите на обилие прослоек, коннекторов и обёрток для независимых библиотек, реализованных в виде extension-пакетов.
Через магический геттер.
Почему не получается? Делайте Model и Repository. Кто мешает?
Я тоже. Одно дело сам фреймворк — в него компоненты удачные перекочевали из тех времён, когда ничего не было. Плюс некоторые запилили с нуля потому как было время на них и могли сделать хорошо. Итеративно улучшать это всё логично потому как оно не хуже альтернатив. Хотя, конечно, временами некоторые части хочется выкинуть и взять что-то, что их переросло. Но обратная совместимость в 2.0 это сделать не позволяет.
Совсем другое дело — проекты. Вот в них чем руководствуются, реализуя с нуля всякое, я не уверен...
Нас, кроме алиасов, интересовала ещё и скорость загрузки классов. На момент релиза Yii лодер Composer-а был совсем плох в этом плане. issue на тему loader-а практически не было, работает всё стабильно, каши не просит.
Алиасами мы для загрузки классов не оперируем. Как и не оперируем неймспейсами для работы с файловой системой.
Так этот факт не меняется вне зависимости от используемого фреймворка. Писать независимые компоненты сложнее, чем завязанные на другой код.
Эволюционные. Будем облегчать ядро, избавляться от всяких jQuery, выкидывать версии PHP до 7-ки, выкидывать HHVM. Выпиливать части в расширения и независимые библиотеки, которые, по возможности, будут поддерживаться заинтересованными разработчиками. Облегчать дерево наследования и стремиться выпилить его совсем...
Революции вроде 1.1 → 2.0 не хочется. По крайней мере пока.
Я, Carsten Brandt, Дмитрий Науменко, Климов Павел, Boudewijn Vahrmeijer.
В Yii вы можете навесить валидатор на соответствующий приватному свойству геттер. А вообще валидировать приватные свойства не в конструкторе и не в сеттере несколько странно.
Нет, в Active Record нельзя. Сам паттерн создан для обратного. Доктрина — не Active Record.
Поясните, как вы хотите получить публичный доступ к private?