DS
А если сейчас наченем как в инжекторе выдумывать, то это только запутает разработчиков. В инжекторе, кстати, там не все кейсы покрыты, вечером проверю еще
Size: a a a
2020 April 08
AM
Штука в том, что если мы сейчас оставим только именованные, а будут ишью по таким кейсам, как у Дмитрия выше с запаковкой параметров, то мы сможем допилить, обратная совместимость сохранится.
Именованные вообще не очень хорошая штука...
AM
Рефакторинг типа rename их не цепляет.
DS
Именованные вообще не очень хорошая штука...
Для конструктора - норм
AM
Ломаться будет...
DS
Ломаться будет...
И так как в инжекторе тоже будет
DS
Запушу тестов часа через два-три
AM
В инжекторе это не везде. Это только в приложении. Мы его сознательно юзаем.
AM
А тут для всего подряд.
AM
В том числе для библиотек, которые на такое не рассчитывают. И правильно делают, ведь как таковая смена имени параметра конструктора ни на что не влияет.
DS
Ну предложи свой вариант для коструктора вида
__construct(MyClass1 $class1, string $path, MyClass2 $class2, int $level = 4)DS
Тут надо задать $path и $level
DS
И второй класс через
Reference::to()Д
Рефакторинг типа rename их не цепляет.
плюсы переваливают минусы
DS
У меня сейчас, если откинуть подстановку по типу, то будет так
'__construct()' => ['class1' => $class1, 'mypath', Reference::to('class2'), 5]Д
@samdark что по композер-плагинским ПР?
DS
У меня сейчас, если откинуть подстановку по типу, то будет так
'__construct()' => ['class1' => $class1, 'mypath', Reference::to('class2'), 5]Или так
'__construct' => [1 => 'mypath', 2 => Reference::to('class2'), 3 => 5 ]DS
Первый параметр заинжектится здесь контейнером
DS
В том числе для библиотек, которые на такое не рассчитывают. И правильно делают, ведь как таковая смена имени параметра конструктора ни на что не влияет.
Ну поменяет стороння библиотека имя параметра - переименуешь в конфиге. А если местами переставит, то как ты сейчас это решать будешь? Тоже сломается.
DS
А еще в сторонних библиотеках могут быть нетипизированные параметры, а их инжектор не поддерживает