Не надо никого заставлять. Это возможность для пакетов, которые имеют поддержку для yii3

В моем варианте я просто добавляю такие сервисы в конфиг config/web-stateful.php в самом пакете, и оно будет автоматически затянуто в нужный рисетейбл контейнер и автоматически сброшено в конце запроса

Поддержка для Yii 3 - это пакеты, которые зависят от Yii 3.

Нет, это пакеты, которые имеют конфиги для контейнера, которые могут быть автоматом смержены и подключены к приложению на yii3. Но это не значит, что я не могу использовать этот пакет в другом фреймворке, это значит только то, что мне надо будет конфиг написать/добавить нужное в контейнер ручками.

Пошёл подумаю ещё и пообщаюсь заодно с Титовым...

И еще раз повторю на всяк случай. В пакете может быть ни одной зависмости вида yiisoft/*, но при этом, если у него есть конфиги и соответсвующая настройка в composer.json, он может быть автоматом подключен в приложение на yii3

А добавить интерфейс Resetable в PSR - это да, было бы очень круто. Но пхп-фиг, или как там его - это слишком неповоротливая организация.

говорящее название )

пхп-фиг

Но вообще, я бы вынес бы вот этот каталог config и настройку, а сделал бы yiisoft-recipes, и допилил бы плагин композера, чтобы он при установке/обновлении пакета, преверял бы наличие рецепта, если есть, то получал бы его, брал бы из него настройки и конфиги и мержил. Таким образом мы бы могли интегрировать любой сторонний пакет, позволив его автоматом подключить к приложению.

samdark:

Ситуация такая:

1. Есть stateless-сервисы.
2. Есть stateful-сервисы.
3. Есть stateful-сервисы с дорогой инициализацией.

1. С ними всё норм.
2. Нужно убивать в контейнере после каждого request-response.
3. По идее, можно сделать метод reset() и дёргать.

Как у вас с этим?

Titov:

1. все ок
2. очень мало их
3. такие не делаем, юзаем ioc скопы https://spiral.dev/docs/framework-scopes - обнуляются при выходе из контекста.


Мы сделали максимальное число сервисов стейтлесс. А что не стейтлесс достается из контекста либо через скоп менеджер.
Короче это решается только на архитектурном уровне.


Пункт 2. - это очень больно. 3. тоже.

Так что мы сделали так что они нафиг не нужны. Если у вас жирный сервис стейтфул то проблема не в скоупе.

samdark:

Ну вот ребята хотят запилить ResetableInterface с методом reset() и научить контейнер вместо убийства в скопе таких вызывать reset().

Titov:

Ну сделают симфони. А смысл? Ресет это по любасу костыль.

Пусть глянут другие языки программирования где все всегда висит в памяти. Никто не пишет ресет.

У меня всего 2 ресера на всю аппу, и то 1 для дебага, 2й для орм хипа чтобы быстрее было. Всё.

Ресет говорит о том что у вас приложение МОЖЕТ находится в грязном состоянии до ресет().
А нужно чтобы оно всегда было в чистом состоянии.

samdark:

Вот у нас как раз на дебаге всплыло :)

Titov:

Ну на дебаге я бы сказал норм. Это очень странный эдж кейс.
Но в бизнес слой я бы такого не тянул потому что дебаг сквозной на всю аппу, а логика обычно нет, работает в контексте запроса.
С ресет() вы сделаете симфони где вся логика сквозная и это не очень безопасно но быстро. Скоупы работают немного медленней.

Если надо могу рассказать, или вебинар сделать. Я с этим уже 4 года.

Scope - это примерно что в PR resetable container, но без интерфейса для сервисов.

Ну то есть подозрения что мы взяли edge case с дебаггером и пытаемся его сделать нормой у меня ещё больше укрепились.

Welcome :)

о, Антона можно теперь тут пинать, даже дискорд запускать не надо

:D

не надо, мне работать надо

:D

привет)

> Пусть глянут другие языки программирования где все всегда > >висит в памяти. Никто не пишет ресет.
В других языках другая архитектура. Здесь же нужно для этого специально писать, на случай если будет использоваться рр. Это то, о чем я говорил, под рр нужно отдельно проектировать приложение,  но если юзать рисетейбл контейнер и рисетейбл объекты, то это можно немного сгладить.