Object build by TyphoonFactoryProvider is not honoring <TyphoonComponentFactoryAware>

[jasperblues]

No description provided.

[drodriguez]

Ok, so as far as I understand, TyphoonComponentFactoryAware just inject the component factory in the instances after the properties.

There are two cases here:

• Using withProtocol:dependencies:returns:: I think I will make TyphoonAssistedFactoryBase conform to TyphoonComponentFactoryAware, which will inject the component factory into the factory itself. Then in -[TyphoonAssistedFactoryBase(TyphoonFactoryMethodClosure) forwardInvocation:] I will inject the factory into the instance. I will have to make “internal” some methods of TyphoonComponentFactory(InstanceBuilder) to not repeat code.
• Using withProtocol:dependencies:factory: and withProtocol:dependencies:factories: are harder, since the instance is built by the user, not us. Capturing those block return values is going to be hard… but maybe possible. It’s going to be slower (has to go through forwardInvocation:).

In case I cannot make it work, I propose relaxing the requisites a little bit: the use inside the block will be the one responsible for injecting the component factory in its object, accesing a property like componentFactory from the first parameter of the block. In my case most of the uses of the factory provider are now using the first method, so I don’t expect this being a hassle for too many people.

I’m going to start working in the first one, and see how far I get for the second one. If anyone sees some problem or thinks I’m going off the rails, please comment.

[jasperblues]

Would be very useful to have the former case supported.

In there latter case, where its the config block that explicitly spells out the dependencies, it does actually sound reasonable to ask the user to specify the factory injection with #131 (which I'll implement and push today). What do you think?

[drodriguez]

Well, there you go. Both factories: and returns: works and they get injected automatically the component factory. It makes the blocks go throught the forwardInvocation: path, but that might be actually good (only one path, not two).

Give it a look, a let me know if it covers your use case, and I will merge into master.

[jasperblues]

👍

Very excellent. Let's merge it in.

[drodriguez]

Done.

I had a strange appearing and disappearing test failure with the cyclic dependency exceptions, but after doing a clean and rebuild they didn’t appear again. I don’t see how I might have introduced such a problem, but if someone sees the problem again, it might be a good thing to investigate if the tests are brittle.

[jasperblues]

Re strange problems: Maybe it was some stale files . . I made a change today that caught an issue about circular deps in initializers - seems we're moving towards raising an exception for that. So I changed the test rules to assert an exception is raised.

I did raise an issue to discuss further though. See it?

(Typed comment on iPhone)