AM
Готово.
Size: a a a
2020 April 06
AM
https://github.com/yiisoft/yii-web/pull/239 тесты фейлит.
DS
https://github.com/yiisoft/yii-web/pull/239 тесты фейлит.
Фейлит потому, что связан с предыдущим. Ну то такое, сейчас есть другие вопросы.
DS
Итак, вопрос первый. Это метод detach. Я понимаю, что он пришел с yii2, но он явно не вписывается в концепцию yii3. Поскольку он позволяет глобально отсоединять обработчики в событии. Мы, например, можем сделать detach(AfterRequest::class), что приведет к непредсказуемым последствиям. Вторая проблема, если мы используем рр, а листенеры конфижатся в прелоаде, то отсоединенный обработчик при текущей реализации детача будет весьма проблемно подсоединить обратно. Можно, конечно, поменять реализацию и хранить отсоединенные обработчики в отдельном массиве, но тогда нам нужен resetable провайдер, который можно сбросить после эмита. Если нам нужно просто остановить обработку какого-то события, то для этого есть псрные stoppable events. Так что вопрос в следующем, если у вас кейсы, в которых не обойтись без полного детача обработчиков определенного события, которые нельзя решить архитектурно без его использования.
AM
У меня нет.
DS
Второй вопрос. Нужна ли нам возможность инжектить зависимости из контейнера в листенеры, которые реализованы анонимками. Я могу это реализовать так, чтобы пакет yiisoft/event-dispatcher ничего не знал об Injector.
AM
Было бы удобно.
Д
Итак, вопрос первый. Это метод detach. Я понимаю, что он пришел с yii2, но он явно не вписывается в концепцию yii3. Поскольку он позволяет глобально отсоединять обработчики в событии. Мы, например, можем сделать detach(AfterRequest::class), что приведет к непредсказуемым последствиям. Вторая проблема, если мы используем рр, а листенеры конфижатся в прелоаде, то отсоединенный обработчик при текущей реализации детача будет весьма проблемно подсоединить обратно. Можно, конечно, поменять реализацию и хранить отсоединенные обработчики в отдельном массиве, но тогда нам нужен resetable провайдер, который можно сбросить после эмита. Если нам нужно просто остановить обработку какого-то события, то для этого есть псрные stoppable events. Так что вопрос в следующем, если у вас кейсы, в которых не обойтись без полного детача обработчиков определенного события, которые нельзя решить архитектурно без его использования.
хочешь выпилить detach?
DS
Третий вопрос. Я сделал альтернативную реализацию с передачей конфига в конструктор провайдера, но без того, чтобы провайдер знал о существовании контейнера. То есть, сначала EventConfiguraor проходится по конфигу и инстанцирует классы в коллейбл массивах и потом уже измененный конфиг передает в конструктор провайдера, а провайдер присоединятет к композитному провайдеру. На текущий момент я прикинул, что нам это дает единственное преимущество, что нам не нужен абстрактный конфигуратор провайдера. В остальном минусы. Нам нужно использовать композитный провайдер вместо обычного. Это значит, что мы можем присоединять листенеры рантайм, создавая новый провайдер и присоединяя его к основному композитному. И хотя это уже не будет нарушением интерфеса, но в этом есть те же минусы, что и с детач. Для работы с рр, нам нужно ансетить такие провайдеры, иначе каждый запрос они будут подсоединятся снова и снова, что приводит к необходимости рисетейбл функционала теперь уже у композитного провайдера. Так что я пришел к выводу, что текущий вариант с абстрактным конфигуратором - более правильное решение. Хотя, возможно, у кого-то есть другое мнение.
DS
хочешь выпилить detach?
Да
AM
Третий вопрос. Я сделал альтернативную реализацию с передачей конфига в конструктор провайдера, но без того, чтобы провайдер знал о существовании контейнера. То есть, сначала EventConfiguraor проходится по конфигу и инстанцирует классы в коллейбл массивах и потом уже измененный конфиг передает в конструктор провайдера, а провайдер присоединятет к композитному провайдеру. На текущий момент я прикинул, что нам это дает единственное преимущество, что нам не нужен абстрактный конфигуратор провайдера. В остальном минусы. Нам нужно использовать композитный провайдер вместо обычного. Это значит, что мы можем присоединять листенеры рантайм, создавая новый провайдер и присоединяя его к основному композитному. И хотя это уже не будет нарушением интерфеса, но в этом есть те же минусы, что и с детач. Для работы с рр, нам нужно ансетить такие провайдеры, иначе каждый запрос они будут подсоединятся снова и снова, что приводит к необходимости рисетейбл функционала теперь уже у композитного провайдера. Так что я пришел к выводу, что текущий вариант с абстрактным конфигуратором - более правильное решение. Хотя, возможно, у кого-то есть другое мнение.
А вопрос?
DS
А вопрос?
Вопрос, оставляем абстрактный конфигуратор или у кого-то есть кейсы, когда вариант с композитным провайдером будет лучше.
AM
У меня кейсов нет.
DS
Ок, тогда ревертнешь реверт или выпилить детач и новый пр сделать?
AM
новый PR
DS
ок, еще раз все проверю и сделаю
DS
И четвертый вопрос, какие кейсы покрывает листенер в виде чистого коллейбл с классом ивента в виде тайпхинта, которые не покрывает способ с явной передачей класса ивента листенера.
AM
И четвертый вопрос, какие кейсы покрывает листенер в виде чистого коллейбл с классом ивента в виде тайпхинта, которые не покрывает способ с явной передачей класса ивента листенера.
Никакие. Просто так короче.
AM
Синтаксический сахар.
DS
Короче, но группировка неудобна в конфиге, если мы все делаем через конфиги, то может его лучше выпилить? Можно и оставить, конечно, но с ним я не могу сделать инжект зависимостей, хотя в способе с явной передачей сделал и все норм работает.