Initializer circular dependencies - support or not?

[jasperblues]

So, we're moving towards raising an exception for circular dependencies in initializers?

I was moving the RaiseCircularInit exception concern over to TyphoonCallStack (better OO and I want to reduce complexity in TCF+InstanceBuilder). .

In doing so, I found a new case that wasn't being detected as yet:

• (void)test_initializer_injected_component_is_correctly_resolved_in_circular_dependency

thoughts?

As we always try to check in green builds, i've changed the test conditions, but we need to decide what to do here. support or not.

[alexgarbarev]

I think moving RaiseCircularInit into TyphoonCallStack is not good idea, because it used here:

[[_stack peekForKey:componentKey] addInstanceCompleteBlock:^(id reference)
{
    [(NSObject*) instance setValue:reference forKey:propertyName];
}];

That means if we init first object with second as init parameter, and second references to first with property, second will wait until first end initialization and then point to first by property.
I think it is ok and expected by user.
I didn't see a reason to not support it.
I'll refactor to move exception from TyphoonCallStack

[alexgarbarev]

Fixed by adding peekInstanceForKey method to TyphoonCallStack class. So if we want to peek only element - don't raise an exception and raise if we want instance.

[jasperblues]

Perhaps its a little bit too surprising to have the two methods with different types of behavior?

I had it like this:

peekForKey:(NSString*)key raiseCircularDependenciesException:(BOOL)raise

. . but was toying with the idea that maybe we don't need that parameter.

I started moving some things out of TCF+InstanceBuilder (was becoming a god-class). . definitely seemed to work for the init invocation - allows using polymorphism by assigning the responsibility of argument setting to the parameters. . . .

I thought it made sense for TyphoonCallStack to take on this responsibility. Perhaps not?

[alexgarbarev]

Yes, I agree that TyphoonCallStack is place for exception. I just want to say that we have to support this circular dependence. It is not hard (or a lot of code) to support.

I can't imagine example of usage, but If user can imagine it, he will be surprised that it is not supported.

[alexgarbarev]

I think better to raise exception in TyphoonStackElement instance getter. I.e. when someone access to instance while it in initializing state -raise exception

[alexgarbarev]

@jasperblues check current implementation, may be it is better

[jasperblues]

Looks g

[jasperblues]

Looks good Aleksey :)