Ну и ладно, живи как знаешь. Чего это я, действительно, проблема то у тебя.
Хватит бисер метать.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Только не странно, а криво.

Да потому же, почему и ты. Меня не все в них устраивало. Что именно, не буду говорить, это не важно в текущем контексте. Но я досконально разбирался в вопросе, прежде чем приступить к реализации. И естественно смотрел, как устроены эти разработки. Почему так, и чем грозит иначе. И я взял из них лучшее, а именно концепцию построения.

Если бы мне тогда кто-то подсказывал, я был бы счастлив.

Ты же взял самое худшее, а сейчас тебе обидно и ты ведешь себя как ребенок:

- Да, крыша у меня протекает, но не так уж сильно, я тазик поставлю.

А последний перл - вообще шибздец:

- Покажи мне реализацию!
- Смотри.
- Не буду смотреть! Зачем ты сюда припер свою игрушку, здесь моя песочница!

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

Ладно, смысла на тебя тратить время больше нет. Я получил от холивара пользу - сделал карту для своей свистоперделки. Мне достаточно. Ты как хочешь. Адью.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Ты просто не понимаешь почему все именно так.

Попытаюсь еще раз пояснить.
Когда ты инициализируешь любую более менее сложную ООП систему, в ней есть классы, для которых будет создан один экземпляр, при том это не синглтоны, они ни чем не отличаются от других классов, просто они так используются системой, обычно я их называю инфраструктурными. Есть же классы, у которых будет много экземпляров, для них у меня названия нет, но можно сказать что это классы текущего запроса пользователя. Цель инфраструктурных классов создать каркас для работы с экземплярами классов текущего запроса пользователя. Инфраструктурные классы обычно ссылают друг на друга и им нужно, что бы их экземпляры имели единое состояния, а не порождались контейнером каждый раз, иначе система развалится.

Пример:
1. PSR-7 Request/Response это экземпляры классов текущего запроса пользователя
2. Фабрика это экземпляр инфраструктурного класса
3. Модуль это экземпляры классов текущего запроса пользователя, который ссылается на экземпляры инфраструктурного класса
4. Адаптар для обращения к метаданных это экземпляр инфраструктурного класса
5. Классы мидлваров это экземпляры классов текущего запроса пользователя, который ссылается на экземпляры инфраструктурного класса

И т.д.

Сложная ООП система имеет разные требования к разных объектам, к их количеству и принципу создания, а также внедрению их в другие объекты. Ты рассуждаешь о том как использовать контейнер на 3 классах, у меня же система на один запрос создает порядка 60-80 экземпляров как инфраструктурных классов так и классов текущего пользователя. На 2-3 классах ты хоть сколько можешь упражняться в словесности, но реально работают твои концепции или нет, покажет только практика.

У тебя есть ABC-Framework, который по сути работает на статическом сервис локаторе, ну так внедри в него свой контейнер и отвяжи фреймворк от сервис локатора, тогда у тебя наконец-то прояснится в башке понимание того о чем я говорю, ты увидишь что объекты разные и жизненный цикл у них разный, и востребованность у каждого объекта разная. То о чем ты говоришь и пытаешься мне впарить как единственно правильный вариант, нужно крайне редко. Нужно порождать новые объекты, но обычно зависимости для порожденных объектов уже должны быть настроены и лежать в контейнере. Ты судишь о моем контейнере на уровне первого использования, я же сужу на уровне построенной сложной системы, у нас разные потребности и требования к DIC.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Крайне неудачный пример. Хуже и придумать нельзя. Знаешь, почему методы там называются withHeader() а не addHeader()? Ну и остальные по аналогии? Многих мучал такой вопрос. Да потому что метод всегда возвращает новый объект. Каждый раз. Даже когда в этом нет необходимости.

По твоей концепции настроенные объекты должны храниться в контейнере. Так кто же против? Дыра в том, что хранятся не только настроенные объекты, но и объекты настройки. И они, в отличие от PSR7, который ты привел в пример, всегда одни и те же. Не одинаковые, а одни.

Тебя не смущает большое количество объектов. Так а почему ты тут экономишь, где явная дырка?

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Ты меня изумляешь такими умозаключениями, ладно это твои проблемы что ты так понимаешь этот стандарт.

Я тебе выше писал, ты видимо читаешь через строки. Я осознаю что у меня течет абстракция в пределах обращения к контейнеру, когда хочется получить экземпляр класса который не должен храниться в контейнере. И я тебе пояснил, почему я в ближайшее время не будут править, так как формально контейнер соответствует PSR-11, а также эта течь локализована фабричным слоем. Так что естественно я экономлю, я уже не 20летний парнишка, энтузиазма не вагон и маленькая тележка, его надо экономить.

Я конечно думаю как это переделать, вот обсуждая с тобой это, пришла странная идея, попробую, может что получится.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Я бы не говорил так, если бы сам не реализовал HTTP по этому стандарту. Все методы with... обязаны возвращать новый объект.

Потому и всегда используется перезапись:

$responce = $responce->withHeader(....);
// Вот так не сработает
$responce->withHeader(....);

Потому что заголовок добавится в новый объект, а он никуда не присвоен.

В новый! А ты хранишь старые объекты зависимостей. Не сервисов, а зависимостей. И используешь их для всех сервисов.

Тебе может гордость не позволяет принять то, что я советую? Ну это же очевидно просто. Поставь принудительно звездочку на зависимость и радуйся. Остальное побоку, твое дело. :)

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Опыт, текущая практика. Твои советы приводят к избыточности в коде, я пытался сменить поведение со звездочками на противоположное, но это приводит к увеличению кодовой базы в контейнере, а карта зависимостей требует проставления везде звёздочек, там где раньше было 3 строки со звездочкой, будет все в звёздочках и 3 строки без звездочки. Избыточность синтаксиса даже говорит, что решение не стыкуется с концепцией. Гордость тут не причем.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации