SU
Всем привет ✌
Size: a a a
2021 March 11
KN
вот казалось бы, да? PHP какие-то штуки крутые внедряет для упрощения, а Symfony умудряется перевернуть всё наоборот с аргументацией "чтоб было" 🙈
О, ты уже заценил что они планируют добавить autoload_runtime, вместо autoload? :D
AM
сразу видно, кто тесты не пишет)))
потому что в тестах сделать new Service($a, $b) проще, чем new Service(); $service->a = $a; $service->b = $b;
потому что в тестах сделать new Service($a, $b) проще, чем new Service(); $service->a = $a; $service->b = $b;
имхо, нужно смотреть на применение и цели, а не только как тесты проще писать (на миллиметр проще)
AM
это ты про uninitialized? или про явный ?Service ?
кроме нула ещё дефолтную реализацию практикуют. Только хз норм ли это решение
MM
кроме нула ещё дефолтную реализацию практикуют. Только хз норм ли это решение
А что мешает это делать в конструкторе?
SU
Не подскажите как можно реализовать пагинацию по товару ?
ES
беги
ES
несмотря даже на правильное приветствие, тут не оценят))
SU
Поподробнее можешь обяснить ?)
AM
А что мешает это делать в конструкторе?
То, что чисто логически зависимость может быть опциональной. Если зависимость опциональна, то, имхо, внедрять через метод или пропертю — адекватно. Без разницы "вручную" или с помощью автовайринга. Только уточню, что если кто-то и решит так делать, то я был бы против варианта с использованием аннотаций прямо в классе. Уж лучше тогда вынесенную в какой-то конфиг конфигурацию.
MM
То, что чисто логически зависимость может быть опциональной. Если зависимость опциональна, то, имхо, внедрять через метод или пропертю — адекватно. Без разницы "вручную" или с помощью автовайринга. Только уточню, что если кто-то и решит так делать, то я был бы против варианта с использованием аннотаций прямо в классе. Уж лучше тогда вынесенную в какой-то конфиг конфигурацию.
Нет, не адекватно
AM
Вот только опциональные зависимости — это редкость.
AM
Нет, не адекватно
Потому что нуллейблы говно? Или по другой причине?
ИЛ
То, что чисто логически зависимость может быть опциональной. Если зависимость опциональна, то, имхо, внедрять через метод или пропертю — адекватно. Без разницы "вручную" или с помощью автовайринга. Только уточню, что если кто-то и решит так делать, то я был бы против варианта с использованием аннотаций прямо в классе. Уж лучше тогда вынесенную в какой-то конфиг конфигурацию.
оно всё ради того, чтоб не выносить в конфиг
AM
оно всё ради того, чтоб не выносить в конфиг
ну вот я против этого
MM
Потому что нуллейблы говно? Или по другой причине?
Для опциональных зависимостей есть тип null, либо налабл реализации.
А вот изменение объекта после создания - как минимум, прицеливание себе в хер. А там и до выстрела рукой подать
А вот изменение объекта после создания - как минимум, прицеливание себе в хер. А там и до выстрела рукой подать
AM
Для опциональных зависимостей есть тип null, либо налабл реализации.
А вот изменение объекта после создания - как минимум, прицеливание себе в хер. А там и до выстрела рукой подать
А вот изменение объекта после создания - как минимум, прицеливание себе в хер. А там и до выстрела рукой подать
Ну так в конструкторе оно и с нулом. А дальше кто-то "опционально" может внедрить опциональную зависимость, если в процессе работы она кому-либо потребовалась.
AM
Или после создания уже не должно быть возможности пробросить зависимость, если она опциональна и не была проброшена сразу?
VC
Или после создания уже не должно быть возможности пробросить зависимость, если она опциональна и не была проброшена сразу?
проблросить возможность может быть, инжектить в класс не надо
ИЛ
если мы делаем сервис потомок с одной дополнительной инъекцией логгера, например, то #[Required] сильно сократит код
конструктор будет от родителя и потомку будет насрать на его возможные изменения
конструктор будет от родителя и потомку будет насрать на его возможные изменения