GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
A module shouldn't be the only way an object can be injected into the injector context outside of the default registration mechanism.
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)whenAskedForProtocol:(Protocol *)protocol supplyInstance:(id)instance;
-(void)whenAskedForProtocol:(Protocol *)protocol supplyClass:(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.
JIT bindings for Guice does this. http://code.google.com/p/google-guice/wiki/JustInTimeBindings.