jbsf / blindside

Blindside provides dependency injection capabilities for Objective-C on iOS and OS X
MIT License
71 stars 43 forks source link

Ahead-of-time runtime configuration validation #50

Open briancroom opened 8 years ago

briancroom commented 8 years ago

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:

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.

tjarratt commented 8 years ago

:+1:

Sent From A Very Small Keyboard

On Jan 23, 2016, at 20:13, Brian Croom notifications@github.com wrote:

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.

— Reply to this email directly or view it on GitHub.

jbsf commented 8 years ago

Sounds like a good idea and a thoughtful approach.

On Sun, Jan 24, 2016 at 7:42 PM, Tim Jarratt notifications@github.com wrote:

:+1:

Sent From A Very Small Keyboard

On Jan 23, 2016, at 20:13, Brian Croom notifications@github.com wrote:

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.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/jbsf/blindside/issues/50#issuecomment-174386397.