Constructor Dependency Injection и извращения

[whirlwind]

и расширения по своей сути гавно не совместимое друг с другом. 100500 хуков которыъ все равно не хватает и приходится делать простыни копипаста оригинального кода (медиавики в том числе).

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

Так а чем инжект сервис локатора не подходит я так и не понял? Один аргумент по соглашению. Наследуй хоть заунаследуйся.

 

[Yoskaldyr]

Так а чем инжект сервис локатора не подходит я так и не понял? Один аргумент по соглашению. Наследуй хоть заунаследуйся.

Так я создал тему чтобы не было сервис локатора, а полноценный конструктор инжектор, понятно что и то и то юзает контейнер.
Сервис локатор херово что слишком жадные зависимости получаются. А так сразу по конструктору видно что нужно данному классу.
Тупо удобство. Сервис локатор норм когда пишут нормальные разработчики, но очень часто получается как всегда. Если уж контейнер где-то явно понадобится то я его явно заинжектю через конструктор (типичный пример фабрики)

И пока есть 2 варианта которые решают эту проблему (да на рефлексии), в одном случае черная магия с yield для передачи $this контекста в другом немного более явно используя splat (...) оператор и да может кешироваться, так что рефлексия почти не будет влиять как во всех современных контейнерах умеющих кешировать скомпилированный конфиг.

 

[Yoskaldyr]

Если бы форум/смs былаб написано на хорошем массовом фреймворке, на той же симфони к примеру, то разработка плагина ничем не отличалась бы от обычного программирования.

Разовый продукт под конкретного заказчика - однозначно да. Здесь не нужна гибкость, а нужна четкая явность.
А когда речь идет о гибкости из разряда возможности вырвать зуб через анальное отверстие, то вот тут стандартные фреймворки требуют допила и иногда серьезного.
И если это было бы просто то хоть один такой продукт уже давно существовал, но это не так...

Вот почему тред называется так как он называется.

 

[grigori]

знаешь, способов вырвать зуб через анус в php хватает, выбирай любой: yield, declare ticks, замыкания, new $factory($class)->$dep1($dep2,$dep3), include 'php://filter/
но если ты не пишешь фреймвок - можно только пожалеть

 

[AmdY]

Фактически это не любимое наследование и является мидлварь подобной реализацией. Т.к. в 99% случаев все методы наследников состоят из собственного кода + вызов parent. Это ничем не отличается от мидлварьного next().

Мне кажется твоя ошибка в этом заблуждении. Ты пытаешься наследованием решить проблему, которая обязана решаться добрасыванием поведение в паплайн (мидлеварь). Твой плагин будет удобвлетворять интерфейсу плагинов и максимум может наследовать какой абстрактный класс из ядра системы, но никак не устраивать цепочки наследования с другими плагинами.

 

[Full-R]

А почему все молчат про Composer? Распарсить исходник, отнестись к namespace, как к папкам, а потом имплементировать пустых дибилов и расширять их бесполезными мудаками, чтобы вас не разработали, гордно называя это дерьмо autoload, финально запрятав в phar, чтобы вообще никто не понял, что вы не программист даже - вот где мсье должны знать толк в извращениях!

 

[Yoskaldyr]

@Full-R ты под чем?