AB
все-таки дефолтом должен быть синглотн… большинство проектов не используют RR, а вне этого контекста че-т не могу себе придумать когда мне нужны будут разные инстансы
Size: a a a
2020 September 22
DS
Это годится как альтернатива ресету контейнеров
Вроде того, просто вообще без синглтонов обойтись будет сложно.
AB
да даже в случае с RR в рамках одного реквеста нужно отдавать один инстанс
DS
все-таки дефолтом должен быть синглотн… большинство проектов не используют RR, а вне этого контекста че-т не могу себе придумать когда мне нужны будут разные инстансы
Синглтоны приведут появлению кучи сервисов с глобальны состоянием
DS
да даже в случае с RR в рамках одного реквеста нужно отдавать один инстанс
для синглтонов да
DS
не факт, а если там какие-нибудь time() при создании используются?
да, с этим плохо, но можно что-то придумать
AB
а как планируется эти синглотоны выставлять? не получится так, что автовайринг не будет работать, т.к. придется все сервисы инициализировать ручками, чтобы делать их синглтонами
А
Это годится как альтернатива ресету контейнеров
как и weak ref :D
DS
как и weak ref :D
Они не работают
DS
а как планируется эти синглотоны выставлять? не получится так, что автовайринг не будет работать, т.к. придется все сервисы инициализировать ручками, чтобы делать их синглтонами
Не, синглтон будут работать так же как и сейчас, инстансы будут хранится в контейнере и в пределах одного запроcа будет отдаваться один и тот же инстанс
А
Вообще мне не нравится идея сделать все сервисы синглтонами. Я думаю лучше сделать несинглтон по дефолту, а для синглтонов сделать спецтег
scope.singlton. Потом надо разделить кеширование объектов и хранение инстанса синглтона, это нужно для приложений, использующих request loop. То есть, если это не синглтон, то мы кешируем объект при первом обращении и потом отдаем его из кеша через клонирование, а если синглтон, то пишем в кеш и клонируем в инстанс, каждый запрос все инстансы сбрасываются, а кеш остается, поскольку за то, что в кеше отвечает предзагрузка.прикинь, какая боль будет для всех, кто привык юзать обычные контейнеры. Для тех, кто захочет попробовать yiisoft/di в своём проекте. И, возможно, для тех, кто сторонний контейнер засунет в yii3 приложение, если в нём будет код с учётом такого поведения контейнера
DS
прикинь, какая боль будет для всех, кто привык юзать обычные контейнеры. Для тех, кто захочет попробовать yiisoft/di в своём проекте. И, возможно, для тех, кто сторонний контейнер засунет в yii3 приложение, если в нём будет код с учётом такого поведения контейнера
Это все решаемо, делаем параметр defaultScope и при значении равном 'scope.singleton' контейнер будет работать как сейчас
DS
Ну или есть более простое и надежное решение - ResetableInterface
AS
чет вы контейнер в сервис локатор превращаете
AM
чет вы контейнер в сервис локатор превращаете
Да вроде нет.
В
Вообще мне не нравится идея сделать все сервисы синглтонами. Я думаю лучше сделать несинглтон по дефолту, а для синглтонов сделать спецтег
scope.singlton. Потом надо разделить кеширование объектов и хранение инстанса синглтона, это нужно для приложений, использующих request loop. То есть, если это не синглтон, то мы кешируем объект при первом обращении и потом отдаем его из кеша через клонирование, а если синглтон, то пишем в кеш и клонируем в инстанс, каждый запрос все инстансы сбрасываются, а кеш остается, поскольку за то, что в кеше отвечает предзагрузка.Если и так, то я бы, наоборот, сделал синглтоны по дефолту. Я пока не нашел в своем коде кейсов, где мне нужен был бы сервис, который необходимо создавать каждый раз заново. Всякие DTO и прочие стейтфул штуки у меня генерируются фабриками, которые, опять-таки, синглтоны и инжектятся в сервисы.
В
Еще вопрос на смежную тему: кто-нибудь в курсе, зачем фабрике контейнер? В этом классе он не используется.
DS
Еще вопрос на смежную тему: кто-нибудь в курсе, зачем фабрике контейнер? В этом классе он не используется.
в ArrayBuilder используется, но реализация ущербная, Вилмер сейчас как раз столкнулся, я тогда исправлял, но захотели как есть оставить, да контейнер в публичном свойстве - мягкого говоря... ах да, я обещал быть толерантнее) Смотрю сейчас фабрику как раз.
AM
Если получится разорвать циклическую зависимость, будет замечательно.
DS
Если получится разорвать циклическую зависимость, будет замечательно.
Пока решил проблему с публичным свойством контейнера и добавил пару тестов.
https://github.com/yiisoft/factory/pull/36
https://github.com/yiisoft/factory/pull/36