You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+3-10
Original file line number
Diff line number
Diff line change
@@ -75,19 +75,16 @@ In order to do so, swift-blade must be told how to obtain instances of each type
75
75
76
76
Let's go back in and add the `@Provider` attribute to the initializers of our classes so that swift-blade knows how to obtain instances of them.”
77
77
78
-
> [!NOTE]
79
-
> An initializer-based `@Provider` must have its return type specified via the `@Provider` attribute's `of` parameter.
80
-
81
78
```swift
82
79
classElectricHeater: Heater {
83
-
@Provider(of: ElectricHeater.self)
80
+
@Provider
84
81
init() {}
85
82
}
86
83
87
84
classThermosiphon: Pump {
88
85
privatelet heater: Heater
89
86
90
-
@Provider(of: Thermosiphon.self)
87
+
@Provider
91
88
init(heater: Heater) {
92
89
self.heater= heater
93
90
}
@@ -97,7 +94,7 @@ class CoffeeMaker {
97
94
privatelet heater: Heater
98
95
privatelet pump: Pump
99
96
100
-
@Provider(of: CoffeeMaker.self)
97
+
@Provider
101
98
init(heater: Heater, pump: Pump) {
102
99
self.heater= heater
103
100
self.pump= pump
@@ -193,7 +190,3 @@ See [API Documentation](https://shackley.io/swift-blade/documentation/blade/) fo
193
190
**Q: How is the dependency graph validated?**
194
191
195
192
Unlike Dagger, a Blade component's dependency graph is validated at runtime immediately upon component initialization. If a dependency does not have a registered provider, a `fatalError` will occur. This is largely due to the fact that the current [macro](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/macros/) implementation does not have context APIs that allow a macro to glean semantic information about types found in a delcaration at the time of expansion. If such an APIs were to be added, this validation could potentially occurr at compile time.
196
-
197
-
**Q: Why do `@Provider`s attached to initializers have to specify their provided type?**
198
-
199
-
Currently, swift macros are not provided with any lexical scope information at the time of expansion, so it isn't possible for a `@Provider` macro to know which type the initializer belongs to otherwise.
Copy file name to clipboardExpand all lines: Sources/Blade/Blade.docc/Pages/Basics/Providers.md
+2-4
Original file line number
Diff line number
Diff line change
@@ -16,13 +16,11 @@ Adding the `@Provider` attribute to an initializer will allow swift-blade to pro
16
16
17
17
The parameters of the type's initializer are its dependencies. When a new instance of that type is needed, swift-blade will obtain instances of all of its dependencies and invoke its initializer.
18
18
19
-
> An initializer-based `@Provider` must have its return type specified via the `@Provider` attribute's `of` parameter.
20
-
21
19
```swift
22
20
classThermosiphon: Pump {
23
21
privatelet heater: Heater
24
22
25
-
@Provider(of: Thermosiphon.self)
23
+
@Provider
26
24
init(heater: Heater) {
27
25
self.heater= heater
28
26
}
@@ -59,4 +57,4 @@ This pattern is commonly used to alias a concrete type to a protocol that it con
0 commit comments