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
Currently, @Dependency can be used to retrieve a single instance of a given Module (optional, required or required and DefaultInitializable). Further, there also exists a variant to query an array of [any Module] (replacing the legacy dynamic dependency property) that is used to declare dependency to a dynamic amount of dependencies. This is inherently untyped.
PR #110 losend the requirement to strictly have a single Module per Swift type and allows to load multiple modules of the same type. @Dependency declared with a single type always choose the module that was loaded first.
However, it is currently not possible to retrieve all loaded modules of a given type.
Solution
Add support for @Dependency to be declared as an array with a specific Module type M. For example like in the code snippet below:
@Dependencyvardevices:[MyBluetoothDevice]
This would effectively function as an array of optional @Dependency declarations (if the module is loaded it is part of the array, otherwise not and the array might be empty). We would need to investigate if it is possible to initialize this @Dependency variant with already initialized modules (e.g., through a strongly typed variant of the DependencyCollection). This requires consideration how this best integrates with the current system. Currently all module values provided to @Dependency are provided as an auto closure and instances from the outside take precedence. This might not be the best solution for this case.
Additional context
Another feature which might be worth investigating is to support retrieving all Modules that conform to a requested protocol like in a declaration like below:
# Allow to load multiple modules of the same type
## ♻️ Current situation & Problem
Currently, Spezi enforces that there is maximum one module of the same
type loaded at a time. By allowing the Module system to used much more
dynamically via #105, we found that certain types of Modules might exist
multiple times in the system (e.g., a Bluetooth device type modeled as a
Spezi Module might have two physical devices connected at the same
time).
This PR makes the necessary infrastructure changes to support loading
multiple modules of the same type. A check that the same module can only
be loaded once is still in place.
Restructuring the `@Dependency` to support multiple modules of the same
type is not trivial and will be addressed in a follow-up PR which is
tracked in #111.
## ⚙️ Release Notes
* Allow to load multiple modules of the same type.
## 📚 Documentation
--
## ✅ Testing
Additional unit testing was added to verify behavior.
## 📝 Code of Conduct & Contributing Guidelines
By submitting creating this pull request, you agree to follow our [Code
of
Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md)
and [Contributing
Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md):
- [x] I agree to follow the [Code of
Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md)
and [Contributing
Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md).
Problem
Currently,
@Dependency
can be used to retrieve a single instance of a given Module (optional, required or required and DefaultInitializable). Further, there also exists a variant to query an array of[any Module]
(replacing the legacy dynamic dependency property) that is used to declare dependency to a dynamic amount of dependencies. This is inherently untyped.PR #110 losend the requirement to strictly have a single Module per Swift type and allows to load multiple modules of the same type.
@Dependency
declared with a single type always choose the module that was loaded first.However, it is currently not possible to retrieve all loaded modules of a given type.
Solution
Add support for
@Dependency
to be declared as an array with a specific Module typeM
. For example like in the code snippet below:This would effectively function as an array of optional
@Dependency
declarations (if the module is loaded it is part of the array, otherwise not and the array might be empty). We would need to investigate if it is possible to initialize this@Dependency
variant with already initialized modules (e.g., through a strongly typed variant of theDependencyCollection
). This requires consideration how this best integrates with the current system. Currently all module values provided to@Dependency
are provided as an auto closure and instances from the outside take precedence. This might not be the best solution for this case.Additional context
Another feature which might be worth investigating is to support retrieving all Modules that conform to a requested protocol like in a declaration like below:
Code of Conduct
The text was updated successfully, but these errors were encountered: