Skip to content
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

Closed
jdewind opened this issue Sep 28, 2011 · 5 comments
Closed

Add 'injectObject' to Injector #11

jdewind opened this issue Sep 28, 2011 · 5 comments

Comments

@jdewind
Copy link
Contributor

jdewind commented Sep 28, 2011

A module shouldn't be the only way an object can be injected into the injector context outside of the default registration mechanism.

@Undistraction
Copy link

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.

@jdewind
Copy link
Contributor Author

jdewind commented Sep 28, 2011

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:

  • JSObjection is a global class registry
  • JSObjectionInjectors provide objects using the global class registry but do not manipulate global state
  • JSObjectionModule defines new bindings that a Injector uses when the class registry is not enough
  • JSObjectionEntry defines how an object is brought into existence

Putting those responsibilities in one place violates single responsibility principle. The perceived convenience is a red herring to me.

@Undistraction
Copy link

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:

  1. I shouldn't have to create a module in order to ask for a Protocol dependency to be satisfied with a class instance. A module is great for grouping a set of related decisions together, but it is overkill for asking for a single dependency to be satisfied and adds unnecessary complexity in these cases.
  2. I would like a unified API that offers the following available to me from inside a module or not (These are taken from an adapter I am using in front of Objection at the moment):

-(void)whenAskedForClassSupplyClass:(Class)clazz;
-(void)whenAskedForClass:(Class)clazz supplyInstance:(id)instance;
-(void)whenAskedForProtocol:(Protocol *)protocol supplyInstance:(id)instance;
-(void)whenAskedForProtocol:(Protocol *)protocol supplyClass:(Class)clazz;
-(void)mapSingleton:(Class)clazz;
-(void)whenAskedForProtocol:(id)protocol supplySingletonOfClass:(Class)clazz;

@jdewind
Copy link
Contributor Author

jdewind commented Sep 28, 2011

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.

@jdewind
Copy link
Contributor Author

jdewind commented Sep 28, 2011

For reference,

JIT bindings for Guice does this. http://code.google.com/p/google-guice/wiki/JustInTimeBindings.

@jdewind jdewind closed this as completed Nov 30, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants