[Accepted] SE-0064: Referencing the Objective-C selector of property getters and setters


(Douglas Gregor) #1

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md

Hello Swift Community,

The review of SE-0064 "Referencing the Objective-C selector of property getters and setters” ran from April 7...12, 2016. The proposal is accepted. Feedback was light but positive, with many considering this to effectively be an obviously-missing piece of the #selector proposal (SE-0022 <https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md>).

We welcome an implementation of this proposal. I’ve filed a ticket at

  https://bugs.swift.org/browse/SR-1239

to track the implementation.

  - Doug


(Jacob Bandes-Storch) #2

Was the syntax fully bikeshedded by the core team before acceptance?
Perusing the API guidelines, one could also imagine:

    #selector(setting: Person.name)
    #selector(forSetting: Person.name)

···

On Thu, Apr 14, 2016 at 3:58 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md

Hello Swift Community,

The review of SE-0064 "Referencing the Objective-C selector of property
getters and setters” ran from April 7...12, 2016. The proposal is
*accepted*. Feedback was light but positive, with many considering this
to effectively be an obviously-missing piece of the #selector proposal (
SE-0022
<https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md>
).

We welcome an implementation of this proposal. I’ve filed a ticket at

https://bugs.swift.org/browse/SR-1239

to track the implementation.

- Doug

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


(Robert Schwalbe) #3

I realize I am quite late to this discussion, so if a public flogging is in order I am willing to accept that (and the rest of this e-mail can be ignored and/or deleted from the archives).

Per my reading of SE-0022, would SE-0064 institute the first exception to the #selector expression where the expression is not a reference to a method?

In the spirit of taking my lumps for not speaking up when asked to do so, was there any discussion that considered:

    let firstNameGetter = #selector(get: Person.firstName)
    let firstNameSetter = #selector(set: Person.firstName)

in lieu of the accepted:

    let firstNameGetter = #selector(getter: Person.firstName)
    let firstNameSetter = #selector(setter: Person.firstName)

My concern would be a growing list of permitted non method name parameters to the #selector expression.


(David Hart) #4

Why? What guideline are you referencing?

···

On 15 Apr 2016, at 09:53, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:

Was the syntax fully bikeshedded by the core team before acceptance? Perusing the API guidelines, one could also imagine:

    #selector(setting: Person.name)
    #selector(forSetting: Person.name)

On Thu, Apr 14, 2016 at 3:58 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md

Hello Swift Community,

The review of SE-0064 "Referencing the Objective-C selector of property getters and setters” ran from April 7...12, 2016. The proposal is accepted. Feedback was light but positive, with many considering this to effectively be an obviously-missing piece of the #selector proposal (SE-0022 <https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md>).

We welcome an implementation of this proposal. I’ve filed a ticket at

  https://bugs.swift.org/browse/SR-1239

to track the implementation.

  - Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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 Hart) #5

Hello Robert,

My comment below:

Per my reading of SE-0022, would SE-0064 institute the first exception to the #selector expression where the expression is not a reference to a method?

Indeed. But I don’t see the issue. It still generates a selector for an Objective-C method.

In the spirit of taking my lumps for not speaking up when asked to do so, was there any discussion that considered:

   let firstNameGetter = #selector(get: Person.firstName)
   let firstNameSetter = #selector(set: Person.firstName)

in lieu of the accepted:

   let firstNameGetter = #selector(getter: Person.firstName)
   let firstNameSetter = #selector(setter: Person.firstName)

My concern would be a growing list of permitted non method name parameters to the #selector expression.

I don’t think get/set was specifically mentioned. My personal opinion is that it does not read well because it reads as an action.


(Jacob Bandes-Storch) #6

http://apple.github.io/swift-internals/api-design-guidelines/

It's a matter of interpretation, but:

    "Prefer method and function names that make use sites form grammatical
English phrases."

Maybe I'm missing something, but I can't figure out how to read
#selector(setter: Person.name). My second suggestion reads clearly as "the
selector for setting Person.name".

Jacob

···

On Fri, Apr 15, 2016 at 5:03 AM, David Hart <david@hartbit.com> wrote:

Why? What guideline are you referencing?

On 15 Apr 2016, at 09:53, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote:

Was the syntax fully bikeshedded by the core team before acceptance?
Perusing the API guidelines, one could also imagine:

    #selector(setting: Person.name)
    #selector(forSetting: Person.name)

On Thu, Apr 14, 2016 at 3:58 PM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote:

Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md

Hello Swift Community,

The review of SE-0064 "Referencing the Objective-C selector of property
getters and setters” ran from April 7...12, 2016. The proposal is
*accepted*. Feedback was light but positive, with many considering this
to effectively be an obviously-missing piece of the #selector proposal (
SE-0022
<https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md>
).

We welcome an implementation of this proposal. I’ve filed a ticket at

https://bugs.swift.org/browse/SR-1239

to track the implementation.

- 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


(Robert Schwalbe) #7

Hello Robert,

My comment below:

Per my reading of SE-0022, would SE-0064 institute the first exception to the #selector expression where the expression is not a reference to a method?

Indeed. But I don’t see the issue. It still generates a selector for an Objective-C method.

Thank you David.

I do agree it generates a selector. My objection would be that there are no Objective-C methods named “getter” or “setter”.

In the spirit of taking my lumps for not speaking up when asked to do so, was there any discussion that considered:

  let firstNameGetter = #selector(get: Person.firstName)
  let firstNameSetter = #selector(set: Person.firstName)

in lieu of the accepted:

  let firstNameGetter = #selector(getter: Person.firstName)
  let firstNameSetter = #selector(setter: Person.firstName)

My concern would be a growing list of permitted non method name parameters to the #selector expression.

I don’t think get/set was specifically mentioned. My personal opinion is that it does not read well because it reads as an action.

I could go along with you that it reads as an action, but I also think we could come up with tons of existing toolbox method names that would also read as actions.

Maybe I am hung up on insisting that the expression must be an actual name of an Objective-C method.


(Douglas Gregor) #8

Hello Robert,

My comment below:

Per my reading of SE-0022, would SE-0064 institute the first exception to the #selector expression where the expression is not a reference to a method?

Indeed. But I don’t see the issue. It still generates a selector for an Objective-C method.

Thank you David.

I do agree it generates a selector. My objection would be that there are no Objective-C methods named “getter” or “setter”.

Objective-C's @property syntax uses "getter" and "setter" to name the getter and setter selectors, and that's the information being extracted by this Swift expression.

  - Doug

···

Sent from my iPhone
On Apr 18, 2016, at 4:11 PM, Robert Schwalbe via swift-evolution <swift-evolution@swift.org> wrote:

In the spirit of taking my lumps for not speaking up when asked to do so, was there any discussion that considered:

let firstNameGetter = #selector(get: Person.firstName)
let firstNameSetter = #selector(set: Person.firstName)

in lieu of the accepted:

let firstNameGetter = #selector(getter: Person.firstName)
let firstNameSetter = #selector(setter: Person.firstName)

My concern would be a growing list of permitted non method name parameters to the #selector expression.

I don’t think get/set was specifically mentioned. My personal opinion is that it does not read well because it reads as an action.

I could go along with you that it reads as an action, but I also think we could come up with tons of existing toolbox method names that would also read as actions.

Maybe I am hung up on insisting that the expression must be an actual name of an Objective-C method.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution