Closed moorewes closed 2 years ago
Ummm... I guess I'd like to know more about when, specifically, such behavior would be useful?
Being about to alter an @Injected value can come in handy when doing mocking and unit tests, and as such I wouldn't want to change the default behavior. But I'd also be leery of making duplicates of all of the @Injected property wrappers without a better understanding of the benefits.
Thanks for the quick reply.
Fair question - this behavior would be useful for the same reason it's useful to have var
s as well as let
s in Swift. Compiler enforced immutability being the main benefit, but perhaps some performance/optimization gains as well.
I can see how this could limit unit testing/mocking flexibility for certain approaches, which would be a consideration when choosing between a variable and a constant.
Disinclined to build this into Resolver at this point in time, especially since as mentioned it would tend to proliferate all of the various property wrappers and since it's relatively trivial you to clone the existing wrapper and implement it yourself if you truly see value in it.
It would be useful to enforce immutability of an injected type.
That way, the property can't be set again after initialization.
Something like:
@InjectedConstant
, which would be just like@Injected
, butwrappedValue
andprojectedValue
would be computed properties, without setters.Thoughts?
(edit: code snippet typo)