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


(Douglas Gregor) #1

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


(Radek Pietruszewski) #2

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Abrahams) #3

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?

···

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

--
-Dave


#4

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 don't see this as *another* automatic translation so much as making the existing objc-> Swift translation somewhat but-directional.

···

On Feb 24, 2016, at 03:31, Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org> wrote:

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Owens II) #5

+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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution