А разве у `iterable` вообще корректно вызывать методы итератора? там же массив может быть. Либо тайпхинт перепутали, но работает за счет того что передают только итераторы
вам не кажется это нарушением SRP и избыточной сцепленностью ради знания имени класса? вы передаете в класс отдельный набор зависимостей для того чтобы вызвать отдельный метод только на этапе компиляции контейнера и в рантайме этот метод абсолютно бесполезен, т.к актуальные данные есть в кэше роутинга
Возможно статья не демонстрирует преимуществ при наследовании, не хватает примеров.
У меня есть подозрение, что функцию `routes` можно объявить как static, иначе создается иллюзия, что `routes` может возвращать разные значения в зависимости от runtime. Но это далеко не так из-за кэширования
Простой интерфейс контроллера — только один метод execute(Request $request): Response
Удобная генерация url по имени класса — $router->url(SomeEndpoint::class)
Удобство рефакторинга — при переименовании или перемещении контроллера не требуется дополнительных действий, например смена имени роута
Не нужно задавать имя роута (но можно при необходимости)
1. Давно есть в нативном symfony через `__invoke()` и controller as a service symfony.com/doc/current/controller/service.html
2. Как вы ниже пишете по тексту работает не всегда. Чаще всего это не работает, когда один и тот же контроллер доступен по нескольим роутам с разными дефолтными значениями, такие ситуации далеко не редкость. Мне кажется весьма неприятным попасть в ситуацию, когда придется полноситью переделать роутинг контроллера ради того, чтобы навесить на него еще один роут
3. Опять же, не всегда работает, т.к. не всегда работает п. 2
4. И снова не всегда работает.
Какие преимущества данного подхода над controller as a service?
Недостаток я вижу один и довольно существенный — вы привязываете контроллер не только к http-kernel, но и к кастомному роутингу и бандлу, что снижает возможность его переиспользования, особенно если вы пишите компонент, предоставляющий контроллеры, типа админок и всяких вьюеров
Legacy desktop solution. Docker Toolbox is for older Mac and Windows systems that do not meet the requirements of Docker for Mac and Docker for Windows. We recommend updating to the newer applications, if possible.
В теории оно все так, «должны сделать». На практике у меня было две карты — в области и в мск. К каждой привязан свой онлайн банк. Заходишь в один — видишь все карты и один счет. Заходишь в другой — видишь все карты и другие счета, среди которых нет первого.
И вишенка на торте, после которого я отказался от использования сбера — я не могу с карты, открытой в области перевести деньги на счет, открытый на московском аккаунте через СБОЛ. т.е. я захожу в СБОЛ, вижу и карту и счет и не могу перевести деньги. приходится переводить сначала на московскую карту, а потом на московский счет
Библиотека, распространяемая через phar — это инструмент, целостный и законченный, по сути является полноценным проектом. Но и в этом случае смысл сомнителен, если есть хорошее покрытие тестами, то гораздо удобней при сборке очередной версии инструмента забрать как минимум последний патч-релиз из имеющихся, а это уже повод не хранить лок. phpunit, например, при сборке phar делает update (если верить build.xml)
Вроде как не особо завязан, если создать экосистему рецептов для других фреймворков и переработать структуру шаблонного проекта на них так, чтобы туда можно было автоматически вставлять\удалять данные, то можно будет подключить и флекс.
Вся привязка к симфони там сейчас только в рецептах, которые по понятным причинам есть только для симфони и околосимфонёвых проектов.
Но, насколько я знаю, можно писать и подключать свои рецепты
Надо отметить, что «написанному» проекту флекс никак не поможет. Даже написанному на симфони. Он помогает быстро стартовать новые проекты
Не понял прикола с установкой 4.0.2 для приложений. Понимаю, что перевод, но все же.
Вы правда читаете все ченджлоги и дифы всех зависимостей каждый день, чтобы понять, надо вам обновляться или нет? Вы в курсе, что транизитивные зависимости вы все равно так не ограничиваете и composer update таких «зафиксированных» зависимостей все равно вам все может «сломать». А если вы зафиксируете еще и все транзитивки (в чем я сомневаюсь, т.к. они еще и меняться имеют свойство), то вы по сути получите тот же Lock файл
Гораздо проще и правильней выставлять ограничение с помощью каретки (или суровей — тильты на minor.major.patch), типа "~4.0.2", и запускать composer update попакетно — типа composer update symfony/symfony. В таком случае вы обновляетесь только в пределах одного пакета и только в пределах его новых патч. релизов (которые не должны ничего ломать, а только фиксить). Если нужно притянуть также зависимости пакета — флаг --with-dependencies
Из полезных советов могу предложить тулзу composer-lock-diff, очень удобно прикладывать к пулл-реквестам внутри команды.
Я называю это «глобально доступные», неважно каким методом ) Проблема как раз таки в том, что вы можете из любого места обратиться к любому компоненту системы даже к тому, который не предусмотрен ограничениями текущего слоя, переданными зависимостями и тд. Вы можете дергать сервисы из моделей, вы не можете просто проверить кто зависит от вашего кода. Все это очень сильно усложняет поддержку кода при командной разработке
Насчет того, полагаться или нет — тут и контекст можно использовать как попало, например передать внешний контекст во внутреннюю функцию. Выше уже сказали — отличие в том, что в go это инструмент языка и его невозможно использовать некорректно, а программную реализацию всегда можно исковеркать
Неудобно, что defer можно применить только внутри метода класса и с использованием обертки. Я бы предложил какую то подобную структуру. Работает автомагически, не требует особых оберток
final class Defer
{
private $actions = [];
public static function create(): self
{
return new self();
}
public function attach(callable $action): self
{
$this->actions[] = $action;
return $this;
}
public function __destruct()
{
$this->release();
}
private function release(): void
{
foreach ($this->actions as $action) {
$action();
}
}
}
function testDefer()
{
$defer = Defer::create()->attach(
function () {
echo 'Deferred start'.PHP_EOL;
}
);
echo 'Sync action'.PHP_EOL;
$defer->attach(
function () {
echo 'async action'.PHP_EOL;
}
);
if (true) {
// Не стал изголяться с fopen и проверками, поэтому if true
throw new \Exception('Exception!');
}
}
try {
testDefer();
} catch (\Exception $exception) {
echo 'Exception caught: '.$exception->getMessage().PHP_EOL;
}
напрашивается закономерный вопрос о декомпозиции этой логики в отдельный сервис и построении загрузчика роутов вокруг нее
вам не кажется это нарушением SRP и избыточной сцепленностью ради знания имени класса? вы передаете в класс отдельный набор зависимостей для того чтобы вызвать отдельный метод только на этапе компиляции контейнера и в рантайме этот метод абсолютно бесполезен, т.к актуальные данные есть в кэше роутинга
У меня есть подозрение, что функцию `routes` можно объявить как static, иначе создается иллюзия, что `routes` может возвращать разные значения в зависимости от runtime. Но это далеко не так из-за кэширования
1. Давно есть в нативном symfony через `__invoke()` и controller as a service symfony.com/doc/current/controller/service.html
2. Как вы ниже пишете по тексту работает не всегда. Чаще всего это не работает, когда один и тот же контроллер доступен по нескольим роутам с разными дефолтными значениями, такие ситуации далеко не редкость. Мне кажется весьма неприятным попасть в ситуацию, когда придется полноситью переделать роутинг контроллера ради того, чтобы навесить на него еще один роут
3. Опять же, не всегда работает, т.к. не всегда работает п. 2
4. И снова не всегда работает.
Какие преимущества данного подхода над controller as a service?
Недостаток я вижу один и довольно существенный — вы привязываете контроллер не только к http-kernel, но и к кастомному роутингу и бандлу, что снижает возможность его переиспользования, особенно если вы пишите компонент, предоставляющий контроллеры, типа админок и всяких вьюеров
docs.docker.com/toolbox/toolbox_install_windows
И вишенка на торте, после которого я отказался от использования сбера — я не могу с карты, открытой в области перевести деньги на счет, открытый на московском аккаунте через СБОЛ. т.е. я захожу в СБОЛ, вижу и карту и счет и не могу перевести деньги. приходится переводить сначала на московскую карту, а потом на московский счет
github.com/sebastianbergmann/phpunit/blob/master/build.xml#L54
Вся привязка к симфони там сейчас только в рецептах, которые по понятным причинам есть только для симфони и околосимфонёвых проектов.
Но, насколько я знаю, можно писать и подключать свои рецепты
Надо отметить, что «написанному» проекту флекс никак не поможет. Даже написанному на симфони. Он помогает быстро стартовать новые проекты
Это кстати не фиксирует минорную версию. Проверить можно здесь
jubianchi.github.io/semver-check
4.2.0 satisfies constraint ^4.0.2
Вы правда читаете все ченджлоги и дифы всех зависимостей каждый день, чтобы понять, надо вам обновляться или нет? Вы в курсе, что транизитивные зависимости вы все равно так не ограничиваете и composer update таких «зафиксированных» зависимостей все равно вам все может «сломать». А если вы зафиксируете еще и все транзитивки (в чем я сомневаюсь, т.к. они еще и меняться имеют свойство), то вы по сути получите тот же Lock файл
Гораздо проще и правильней выставлять ограничение с помощью каретки (или суровей — тильты на minor.major.patch), типа "~4.0.2", и запускать composer update попакетно — типа composer update symfony/symfony. В таком случае вы обновляетесь только в пределах одного пакета и только в пределах его новых патч. релизов (которые не должны ничего ломать, а только фиксить). Если нужно притянуть также зависимости пакета — флаг --with-dependencies
Из полезных советов могу предложить тулзу composer-lock-diff, очень удобно прикладывать к пулл-реквестам внутри команды.
github.com/yiisoft/yii2-app-basic/blob/master/web/index.php#L12
(new yii\web\Application($config))->run();
т.е. не факт что выйдет создать один раз приложение, и пихать туда реквест на обработку в цикле
github.com/yiisoft/yii2/blob/master/framework/base/Application.php#L129-L137
github.com/yiisoft/yii2/blob/master/framework/base/Application.php#L197-L198
Yii::app()
, так что нет, не можете. Могу правда ошибаться тут, давно уже не пишу на Yiiэто правда единственная опасность глобально доступных переменных на ваш взгляд?
Насчет того, полагаться или нет — тут и контекст можно использовать как попало, например передать внешний контекст во внутреннюю функцию. Выше уже сказали — отличие в том, что в go это инструмент языка и его невозможно использовать некорректно, а программную реализацию всегда можно исковеркать
Sync action
Deferred start
async action
Exception caught: Exception!