А
не проще )
Size: a a a
2021 January 26
А
как раз будет то, о чём говорит кот
А
ты очистишь то, что где-то зависло
AM
Ну если ты после эмиттера чекаешь пустой или нет, то можно по-простому вместо этого вызвать ->reset()
А
то, у чего ref_count Больше одного
DS
Тупо очищаемый контейнер.
И он не будет работать в паре с неочищаемым по той же причине
AM
Залипать будет в $rootContainer?
AM
Да вроде нет...
DS
Залипать будет в $rootContainer?
Внутри сервисов в этом контейнере
AM
очищаемый -> обычный рут
AM
А, не.
AM
Так фолбечнется.
А
ну не могу я быть настолько тупым. Я всё-равно буду думать, что вы что-то не понимаете, либо я вас не понимаю :)
С weakref мы
1 всегда можем задетектить нежелательный стейт, т.к. он гдето залипнет, а значит и в контейнере тоже.
2 Если что-то гдето залипнет и мы не остановим программу, то мы не потеряем залипший стейт а получим его снова при запросе
С weakref мы
1 всегда можем задетектить нежелательный стейт, т.к. он гдето залипнет, а значит и в контейнере тоже.
2 Если что-то гдето залипнет и мы не остановим программу, то мы не потеряем залипший стейт а получим его снова при запросе
А
главное грамотно раскидать по контейнерам
А
сервисы в один, всё остальное в другой
AM
Один контейнер с wek ref мб и будет работать. А вот два где один weak, другой нет — по идее, нет.
А
если не раскидаем, то сервисы будут пересоздаваться
DS
Смотри есть необнуляемый контейнер С1 и обнуляемый С2. В С1 есть сервис А, а в С2 сервис Б. Сервис Б есть в конструктора сервиса А. Если ты получил из композитного контейнера сервис А, то он закешируется в С1 и внутри него уже будет экземпляр сервиса Б. Даже если ты очистишь С2, то в С1 останется сервис А со старым экземпляром сервиса Б.
А
не будет такого, что "очистишь"
DS
В случае со слабыми ссылками будет то же, только в сервисе А сервис Б превратится в нул.