[swift-evolution] [Idea] "Add needless words" to Objective-C method names

[Dave Abrahams]

on Tue Feb 23 2016, Douglas Gregor <swift-evolution at swift.org> wrote:

> Hi all,
>
> One interesting aspect of the Swift API guidelines is that the obvious
> mapping from Swift method names to Objective-C selectors produces poor
> method names for Objective-C code. For example, this
>
> 	func object(at index: Int) -> AnyObject { /* … */ }
>
> will produce the Objective-C selector “objectAt:”, which is not great
> for Objective-C, where one rarely has a preposition at the end of a
> selector piece.
>
> This will, in general, be an issue because the naming guidelines for
> Swift and Objective-C differ so much. We could potentially improve
> those cases where we have an argument label that ends in a preposition
> (like this example) by appending the parameter name when we’re forming
> the selector. For the object(at:) method above, it would produce the
> selector “objectAtIndex:”.

I think maybe you want to take the noun from the type name, with special rules
like s/atInt/atIndex/ applied as a postprocessing step.

> We would probably want to strip a leading article (a/an/the) from the parameter name, so that:
>
> 	func conforms(to aProtocol: Protocol) -> Bool { /* … */ }
>
> ends up with the selector “conformsToProtocol:” (good) rather than “conformsToAProtocol:” (not so good).

I really don't like using the parameter name to derive these nouns
because it will result in suboptimal Swift code (and especially doc
comments) as people try to tune their interfaces for ObjC export.

> The primary benefit to doing this is that we’ll produce slightly
> better Objective-C selectors in cases where we would be producing very
> bad ones (trailing prepositions are *rarely* used in Objective-C), so
> (potentially) fewer Swift methods will need to provide Objective-C
> method names explicitly via @objc(…).
>
> The major downsides are that it is a breaking change for anyone using
> prepositions as argument labels now (and living with the poor
> Objective-C names) and that developers won’t be able to guess what
> Objective-C selector will be formed from a given Swift method without
> having read this message.
>
> Thoughts?

I'm not sure this is a problem we need to fix.  Are you?

-- 
-Dave