Update 1.5.4 #185
Update 1.5.4 #185
Conversation
- @injected → @ResolverInjected - @OptionalInjected → @ResolverOptionalInjected - @LazyInjected → @ResolverLazyInjected - @WeakLazyInjected → @ResolverWeakLazyInjected - @InjectedObject → @ResolverInjectedObject This resolves naming conflicts with the Factory DI framework when both are used together.
0x0sky
left a comment
0x0sky
left a comment
There was a problem hiding this comment.
Cool, but take a look at the comments — there’s a genuine intention to help polish this.
| } | ||
|
|
||
|
|
||
| class InjectedCyclicA { |
There was a problem hiding this comment.
why didn't you use a 'final' keyword?
'
Swift gives us a final keyword just for this purpose: when you declare a class as being final, no other class can inherit from it. This means they can’t override your methods in order to change your behavior – they need to use your class the way it was written.
'
There was a problem hiding this comment.
Just noting that those are tests and not part of the library per se.
There was a problem hiding this comment.
You were right+ It was only later that I noticed the word test!
| @ResolverInjected(name: "fred") var service: XYZNameService | ||
| } | ||
|
|
||
| class NamedInjectedViewController2 { |
There was a problem hiding this comment.
y didn’t you use the final keyword here (if it isn’t already inherited)?
| @discardableResult | ||
| public static func register<Service>(_ type: Service.Type = Service.self, name: Resolver.Name? = nil, | ||
| factory: @escaping ResolverFactory<Service>) -> ResolverOptions<Service> { | ||
| factory: @escaping ResolverFactorySendable<Service>) -> ResolverOptions<Service> { |
|
|
||
| class ContainerInjectedViewController { | ||
| @Injected(container: .custom) var service: XYZNameService | ||
| @ResolverInjected(container: .custom) var service: XYZNameService |
There was a problem hiding this comment.
Do we need this outside the class?
In Ruby, I’d usually keep properties as isolated as possible.
Swift tends to rely more on access-level modifiers.
|
Several things. First, Resolver is deprecated in favor of Factory. Second, renaming major components is a breaking change and would be outside of a point release. Third, and in light of the first two cases, I see no need to use both libraries in the same project. |
3 participants
rename property wrappers to avoid clash with Factory ones