By default, greedily choose the longest satisfiable constructor

[rhgills]

Ala PicoContainer (see third from the top, How does PicoContainer decide what constructor to use?), this should reduce the number of instances in which you must manually set the selector on the initializer. It's particularly painful to do so, at least in Xcode, as the selectors suggested for autocomplete are not necessarily on the class you're actually trying to initialize.

[jasperblues]

This would be cool. . . how would it effect performance? If the impact is minimal (I would assume yes), then I'm good with it.

[rhgills]

Should be easy to implement and performant. I'm thinking just grab all the selectors, select those that begin with init, and pick the longest one. I'll see what I come up with.

[jasperblues]

Note that the Objective-C runtime allows type introspection on properties/selector return values, but not for parameter arguments. . . Therefore it will still be necessary to a) declare parameters in the correct order or b) Specify an index

[rhgills]

Interesting limitation. Thanks for the heads up.

[jasperblues]

AppCode does a nice job with both initializers and property names:

[jasperblues]

I think the type introspection on method params limitation of objective-c would mostly kill this feature. Should we close?

[rhgills]

It could still be implemented without the satisfiable part, by defaulting to the constructor (identified via the init prefix) with the most arguments and still requiring you to call -injectWithDefinition.

But on the other hand, by doing so you lose the clarity of seeing the selector in the initializer block. So you'd be calling -injectWithDefinition a few times and there would be no way (without jumping to the definition of the class you are instantiating) to notice if you're calling -injectWithDefinition with the correct parameters for the selector that is being used.

I agree, it seems like allowing the omission of the selector given these limitations would invite more harm then good.

[jasperblues]

"I think the type introspection on method params limitation of objective-c would mostly kill this feature. Should we close?"

. . . Actually I don't know what I was thinking when I wrote that! It doesn't prevent the feature at all! . .

All the same, I'd prefer the following:

• We make it explicit.
• The IDE gives code completion. If there's just one chooses that. If there's more than one, shows the selectors for that class.

This is quite possible with an AppCode plugin. . . not sure how to tackle it with Xcode.

[rhgills]

I agree, it seems like an IDE issue. I don't think we should change the semantics of the @selector directive, but providing some additional autocomplete in the initialization block would be great! Say, when choosing to autocomplete the block, automatically or manually pick the selector depending on ambiguity and then fill in the initializer.selector = line.

[jasperblues]

I already get some of the way there using this live template in AppCode:

return [TyphoonDefinition withClass:[$CLASS$ class] initialization:^(TyphoonInitializer* initializer)
{
initializer.selector = @selector($selector$);
}];

. . . pressing control-space on selector gives a huge list though. . . Having it default to one or show a list of options just for that class requires a plugin. . I've done some research into the plugin, and I think it would take 1-2 weeks of full-time work. . . .

. . if a framework becomes popular, Jetbrains usually provide built-in support - installing the plugin by default. . . eg, as they've done for CocaoPods.

On Sep 9, 2013, at 11:05 PM, Robert Gilliam notifications@github.com wrote:

I agree, it seems like an IDE issue. I don't think we should change the semantics of the @selector directive, but providing some additional autocomplete in the initialization block would be great! Say, when choosing to autocomplete the block, automatically or manually pick the selector depending on ambiguity and then fill in the initializer.selector = line.

—
Reply to this email directly or view it on GitHub.

[rhgills]

Sounds like something for the future, then! Bigger fish to fry at the moment. :)