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

[David Owens II]

+1 to this. The rules are getting extremely complicated to keep straight already, adding more special cases doesn't help.

If the API name sucks, there's already a mechanism to change how it's exported to ObjC.

-David


> On Feb 24, 2016, at 12:31 AM, Radosław Pietruszewski via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution