-
Notifications
You must be signed in to change notification settings - Fork 223
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add 'injectObject' to Injector #11
Comments
I think the way to approach this is to have a unified API offered by JSObjection allowing registration and bindings which is then used by modules as a convenient way of grouping these decisions/actions in one place. In fact I think it would greatly simplify the API if the idea of registering and the idea of bindings were unified as they are essentially the same thing to someone using the API. Anything that can be done in a module should be able to be achieved outside the module. |
I don't think I'll move those kind of mechanisms into JSObjection since I set it up to act as class registry for Injectors to use for creating dependencies. The responsibilities are as follows:
Putting those responsibilities in one place violates single responsibility principle. The perceived convenience is a red herring to me. |
True. And I'm probably just being myopic, but I'm not suggesting you merge any of those classes or violate the SRP. I suppose I'm saying two things:
-(void)whenAskedForClassSupplyClass:(Class)clazz; |
It appears that you are asking for another registry mechanism for protocols. The reason I've avoided that is that protocols are used sparingly in Objective-C outside of the delegate pattern. |
For reference, JIT bindings for Guice does this. http://code.google.com/p/google-guice/wiki/JustInTimeBindings. |
A module shouldn't be the only way an object can be injected into the injector context outside of the default registration mechanism.
The text was updated successfully, but these errors were encountered: