We allow after property injection methods. . .how about a post-construct block?

[jasperblues]

No description provided.

[jasperblues]

Any thoughts @rhgills ?

[rhgills]

How does this differ from 's -setAssembly: or -afterPropertiesSet? Both of those are called after an object is both allocated and injected (which is what I think of when I hear 'constructed'). And do you mean a block or a method? If its a block, what class holds the block and calls it?

[rhgills]

Ahh I see what you mean! Example here: #75 (comment)

[rhgills]

Makes me a bit uneasy - at least looking at your example, it looks like we're using the post construct block to perform manual dependency injection. And if the motivation is to help with circular dependencies, you still have a problem if there is a circular dependency in the post construct block. I'm not sure what the Definition has business knowing about (knowing in the sense of holding an executable block that does something) that should happen after construction.

[jasperblues]

Its exactly the same thing, but would allow you to set it on the TyphoonAssembly subclass as follows:

- (id)loginController
{
    return [TyphoonDefinition withClass:[MPLoginController class] properties:^(TyphoonDefinition* definition)
    {
        [definition injectProperty:@selector(authorizationUrl) withValueAsText:@"${oauth.authorization.url}"];
    } post-construct:^(MPLoginController* controller)
    {
         //Do some stuff you might normally to in afterProperties set, but that communicates its intention better here
    }];
}

This would just be for those cases where the post-construction steps are really a config detail, and so make sense to go in with the assembly wiring. . . benefits outweigh the confusion of having another approach?

[jasperblues]

Hmmmm. . . . Ok, thanks for the feedback. .

[rhgills]

Hmm, okay, for configuration that might be beneficial.

Where should configuration go, like the authorizationUrl above? As a 'dependency' or as a post construct step? Does configuration belong in the DI container?

[jasperblues]

I'm thinking the whole method relates to the configuration and assembly of the component. So it could be either.

In the above case we're resolving the config from a properties file. Whereas post-construct is something that happens to the component just before Typhoon is done with it. . . so probably the former.

We already have two ways of doing this:

• Implement TyphoonPropertyInjectionDelegate . . . benefit is that its clear and a standard contract. Drawback is that its "invasive" . . you need to depend on Typhoon in your class, either directly or via a category.
• You can specify a custom method name on the definition.

This would be introducing a 3rd way. . . similar to how Spring has the above two ways, as well as the @PostConstruct annotation. . . (As an aside: We could also have a macro to fake the annotation, if we wanted).

After hearing your thoughts, its sounds like marginal benefit though. . . . lets shelve it for now.

[rhgills]

Yeah ill admit I haven't run into any situations myself where this would be a large help; or if I have I haven't realized that this would be of use. I'm of the mind that the current approaches invasiveness is of use because something that needs to be done to the object, post construction, always, seems like a smell; perhaps of needless complexity.

Agree to shelve for now.