весит на методе этого класса?
Да в любом случае. Декоратор зависит от каких то деталей класса, на который вешается. Это не должно так работать, прелесть декоратора то в том, что целевой класс от него никак не зависит
Вы идеалист. На практике отклонение от идеала позволяет элегантно и эффективно решать широкий класс задач. Программирование - это про компромиссы, а не про соответствие идеалам. И не только программирование.
Расскажите, какую проблему решит декоратор, давайте так уж. По мне - лучше сделать, чтоб я глядя на код, понимал, что там, а не чтоб он ломался из за того, что я решил, условно, удалить неиспользуемый аргумент конструктора, который на самом деле нужен декоратору. Я просто прошёл в какой то момент этот этап и я тоже делал в декораторах inject
Вы не ответили на вопрос с нормальным примером кастомного декоратора. На этот inject есть документация, как минимум, и это известное поведение, которое несёт смысл. Да и это известное поведение DI любого, можете так же и без Inject что нибудь ожидать в конструкторе и не получить. Только будет нормальная ошибка Ну и типизация в любом случае не гарантируется, это ж js под капотом, даже без декораторов
Когда вы используете свой собственный декоратор, то его поведение не должно быть загадкой. Ну а нормальную обработку ошибок сделать тоже дело техники.
Обсуждают сегодня