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

Douglas_Gregor · 2016-04-14T22:58:51.000Z

Proposal link: swift-evolution/0064-property-selectors.md at master · apple/swift-evolution · GitHub

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

[SR-1239] Implement SE-0064: Referencing the Objective-C selector of property getters and setters · Issue #43847 · apple/swift · GitHub

to track the implementation.

- Doug

jtbandes · 2016-04-15T07:53:17.000Z

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

[SR-1239] Implement SE-0064: Referencing the Objective-C selector of property getters and setters · Issue #43847 · apple/swift · GitHub

to track the implementation.

- Doug

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

Robert_Schwalbe1 · 2016-04-16T18:20:57.000Z

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.

hartbit · 2016-04-15T12:03:50.000Z

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

  [SR-1239] Implement SE-0064: Referencing the Objective-C selector of property getters and setters · Issue #43847 · apple/swift · GitHub

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

hartbit · 2016-04-18T18:04:59.000Z

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.

jtbandes · 2016-04-15T16:43:40.000Z

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

[SR-1239] Implement SE-0064: Referencing the Objective-C selector of property getters and setters · Issue #43847 · apple/swift · GitHub

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_Schwalbe1 · 2016-04-18T23:11:20.000Z

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 · 2016-04-19T01:45:06.000Z

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