This is both an RFC as well as a "todo" reminder for myself, or another enterprising contributor.
Objective-C's dynamic nature and the way Blindside interacts with it means that only a limited amount of compile-time checking can be performed on an injector's configuration and classes' dependency declarations. Additionally, runtime validity checking is performed on a just-in-time basis, resulting in the possibility of unexpected exceptions lurking behind every call to ``getInstance:`. I would propose providing opt-in ahead-of-time validity checking, available at the time of injector instantiation, after module configuration has been performed.
I imagine these checks could be run as part of an integration test suite, or even upon standard app launches for debug builds.
I've thought of the following possible checks so far:
- Ensure that all classes'
BSInitializerdeclarations refer to an available initializer method (see -[BSInitializer validate]
- Ensure all
BSInitializer argument keys actually exist (a key can be considered to exist if it either a) is explicitly bound in the injector, or b) is a class which Blindside can construct without binding.)
- Ensure all
BSPropertySet declarations refer to usable properties on the class (see -[BSProperty determineReturnType])
- Ensure all
BSPropertySet bindings refer to keys which actually exist
- Check for obvious circular dependencies
I would suggest that the entry point for these checks be a new method introduced on the Blindside factory class which expands upon the existing methods, adding one or more extra parameters for opting into the configuration validity checking. Using a bit mask option set or a parameter object could be a good way to allow future extensions to this feature without requiring breaking API changes.
This is both an RFC as well as a "todo" reminder for myself, or another enterprising contributor.
Objective-C's dynamic nature and the way Blindside interacts with it means that only a limited amount of compile-time checking can be performed on an injector's configuration and classes' dependency declarations. Additionally, runtime validity checking is performed on a just-in-time basis, resulting in the possibility of unexpected exceptions lurking behind every call to ``getInstance:`. I would propose providing opt-in ahead-of-time validity checking, available at the time of injector instantiation, after module configuration has been performed.
I imagine these checks could be run as part of an integration test suite, or even upon standard app launches for debug builds.
I've thought of the following possible checks so far:
BSInitializerdeclarations refer to an available initializer method (see-[BSInitializer validate]BSInitializerargument keys actually exist (a key can be considered to exist if it either a) is explicitly bound in the injector, or b) is a class which Blindside can construct without binding.)BSPropertySetdeclarations refer to usable properties on the class (see-[BSProperty determineReturnType])BSPropertySetbindings refer to keys which actually existI would suggest that the entry point for these checks be a new method introduced on the
Blindsidefactory class which expands upon the existing methods, adding one or more extra parameters for opting into the configuration validity checking. Using a bit mask option set or a parameter object could be a good way to allow future extensions to this feature without requiring breaking API changes.