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

[Radosław Pietruszewski]

I don’t think `objectAt:` or `conformsTo:` are that bad, even in Objective-C.

It’s not standard naming practice, perhaps, but I’m not sure it’s worth having *another* automatic translation/re-naming mechanism to optimize for Objective-C’s conventions. I’m sure there are cases now where translating good Swift names produces ObjC results you can’t live with — and that sucks because then you have to do @objc. But with an automatic translator like what you’re suggesting, maybe most methods will be somewhat more ObjC-like, but you’ll *still* have results you’ll have to correct with @objc. Perhaps even more of them.

> 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),

Rarely used, sure. Uncomfortable, yes. But again, I don’t see how “conformsTo:” or even “objectAt:" is *very bad*.

— Radek

> On 24 Feb 2016, at 06:25, Douglas Gregor via swift-evolution <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:”.
> 
> 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).
> 
> 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?
> 
> 	- Doug
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution