In Java with Spring, you already get this via @Autowired/@Inject, though that's of course a framework-level rather than a language-level feature. (this mindset is a big reason why I favour field injection over constructor injection)
I think this would be possible in .Net if you use attributes on the properties.
What I like about constructor injection is that the dependency requirement is by 'contract' regardless of how you compose. Even without a DI framework there's still only 1 way to compose the object.
I can see how field injection could be more practical. I should ask my Java colleagues about Dependency Injection in Spring :)
Also in the Java world, people with strong views on DI tend to favour constructor injection, generally because it's more 'pure' (i.e. not bound to a DI framework and manually usable).
I see these kinds of fields as a special kind of field (similar to in your post) and as such see the use of the constructor as pointless boilerplate at best and a loss of pertinent semantics at worst).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In Java with Spring, you already get this via @Autowired/@Inject, though that's of course a framework-level rather than a language-level feature. (this mindset is a big reason why I favour field injection over constructor injection)
I think this would be possible in .Net if you use attributes on the properties.
What I like about constructor injection is that the dependency requirement is by 'contract' regardless of how you compose. Even without a DI framework there's still only 1 way to compose the object.
I can see how field injection could be more practical. I should ask my Java colleagues about Dependency Injection in Spring :)
Also in the Java world, people with strong views on DI tend to favour constructor injection, generally because it's more 'pure' (i.e. not bound to a DI framework and manually usable).
I see these kinds of fields as a special kind of field (similar to in your post) and as such see the use of the constructor as pointless boilerplate at best and a loss of pertinent semantics at worst).