[Idea] Make Boolean @objc properties reflect better into Objective-C


(Douglas Gregor) #1

Hi all,

The Swift API guidelines state that Boolean properties should reflect assertions about the receiver, so in Swift one would expect:

  class Foo {
    var isEnabled: Bool // good
  }

rather than

  class Foo {
    var enabled: Bool // not Swifty
  }

When the property is @objc, e.g.,

  class Foo : NSObject {
    @objc var isEnabled: Bool
  }

The resulting Objective-C property doesn’t follow the Cocoa guidelines for Objective-C <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284-BAJGIIJE>:

  @property (readwrite,nonatomic) BOOL isEnabled;

because those guidelines state that properties do not use the “is” prefix.

My proposal is to strip the “is” prefix from the Objective-C name, but leave it off the getter, e.g.,

  @property (readwrite,nonatomic,getter=isEnabled) BOOL enabled;

The change would have no effect on the Swift name; it will only affect the Objective-C property name and setter name.

Thoughts?

  - Doug


(Jordan Rose) #2

+1 from me.

···

On Feb 23, 2016, at 13:00, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

The Swift API guidelines state that Boolean properties should reflect assertions about the receiver, so in Swift one would expect:

  class Foo {
    var isEnabled: Bool // good
  }

rather than

  class Foo {
    var enabled: Bool // not Swifty
  }

When the property is @objc, e.g.,

  class Foo : NSObject {
    @objc var isEnabled: Bool
  }

The resulting Objective-C property doesn’t follow the Cocoa guidelines for Objective-C <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284-BAJGIIJE>:

  @property (readwrite,nonatomic) BOOL isEnabled;

because those guidelines state that properties do not use the “is” prefix.

My proposal is to strip the “is” prefix from the Objective-C name, but leave it off the getter, e.g.,

  @property (readwrite,nonatomic,getter=isEnabled) BOOL enabled;

The change would have no effect on the Swift name; it will only affect the Objective-C property name and setter name.

Thoughts?

  - Doug

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


(Dave Abrahams) #3

+1

···

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

My proposal is to strip the “is” prefix from the Objective-C name, but leave it off the getter, e.g.,

  @property (readwrite,nonatomic,getter=isEnabled) BOOL enabled;

The change would have no effect on the Swift name; it will only affect the Objective-C property name and setter name.

Thoughts?

--
-Dave


(Jeff Kelley) #4

+1. This definitely matches my real-world use of boolean properties across
both languages.

Jeff Kelley

SlaunchaMan@gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan> |
jeffkelley.org

···

On Tue, Feb 23, 2016 at 4:00 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

Hi all,

The Swift API guidelines state that Boolean properties should reflect
assertions about the receiver, so in Swift one would expect:

class Foo {
  var isEnabled: Bool // good
}

rather than

class Foo {
  var enabled: Bool // not Swifty
}

When the property is @objc, e.g.,

class Foo : NSObject {
  @objc var isEnabled: Bool
}

The resulting Objective-C property doesn’t follow the Cocoa guidelines
for Objective-C
<https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284-BAJGIIJE>
:

@property (readwrite,nonatomic) BOOL isEnabled;

because those guidelines state that properties do not use the “is” prefix.

My proposal is to strip the “is” prefix from the Objective-C name, but
leave it off the getter, e.g.,

@property (readwrite,nonatomic,getter=isEnabled) BOOL enabled;

The change would have no effect on the Swift name; it will only affect the
Objective-C property name and setter name.

Thoughts?

- Doug

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


(Radek Pietruszewski) #5

Seems like an easy win, so I’m leaning towards a +1.

OTOH, are there any other cases where Swift -> ObjC automatically changes names of things to optimize for ObjC? If we don’t do more of that (the '"Add needless words" to Objective-C method names’ thread, or other quick wins like this one), it would be weird to make just this one exception, a single special case. I fear this would be more surprising than not changing anything at all.

— Radek

···

On 23 Feb 2016, at 22:00, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

The Swift API guidelines state that Boolean properties should reflect assertions about the receiver, so in Swift one would expect:

  class Foo {
    var isEnabled: Bool // good
  }

rather than

  class Foo {
    var enabled: Bool // not Swifty
  }

When the property is @objc, e.g.,

  class Foo : NSObject {
    @objc var isEnabled: Bool
  }

The resulting Objective-C property doesn’t follow the Cocoa guidelines for Objective-C <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284-BAJGIIJE>:

  @property (readwrite,nonatomic) BOOL isEnabled;

because those guidelines state that properties do not use the “is” prefix.

My proposal is to strip the “is” prefix from the Objective-C name, but leave it off the getter, e.g.,

  @property (readwrite,nonatomic,getter=isEnabled) BOOL enabled;

The change would have no effect on the Swift name; it will only affect the Objective-C property name and setter name.

Thoughts?

  - Doug

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


(Rod Brown) #6

+1. I’ve been dealing with this quite a lot recently. Great solution.

···

On 24 Feb 2016, at 8:00 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

The Swift API guidelines state that Boolean properties should reflect assertions about the receiver, so in Swift one would expect:

  class Foo {
    var isEnabled: Bool // good
  }

rather than

  class Foo {
    var enabled: Bool // not Swifty
  }

When the property is @objc, e.g.,

  class Foo : NSObject {
    @objc var isEnabled: Bool
  }

The resulting Objective-C property doesn’t follow the Cocoa guidelines for Objective-C <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284-BAJGIIJE>:

  @property (readwrite,nonatomic) BOOL isEnabled;

because those guidelines state that properties do not use the “is” prefix.

My proposal is to strip the “is” prefix from the Objective-C name, but leave it off the getter, e.g.,

  @property (readwrite,nonatomic,getter=isEnabled) BOOL enabled;

The change would have no effect on the Swift name; it will only affect the Objective-C property name and setter name.

Thoughts?

  - Doug

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


(Douglas Gregor) #7

Seems like an easy win, so I’m leaning towards a +1.

OTOH, are there any other cases where Swift -> ObjC automatically changes names of things to optimize for ObjC? If we don’t do more of that (the '"Add needless words" to Objective-C method names’ thread, or other quick wins like this one), it would be weird to make just this one exception, a single special case. I fear this would be more surprising than not changing anything at all.

We do a bunch of this already. We join the first argument label to the base name to form the first selector piece, inserting “with” if there’s no preposition in between already, and for throwing methods we either add “error:” in the appropriate place or append “AndReturnError” to the first selector piece if there are no other parameters.

  - Doug

···

On Feb 24, 2016, at 12:36 AM, Radosław Pietruszewski <radexpl@gmail.com> wrote:

— Radek

On 23 Feb 2016, at 22:00, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

The Swift API guidelines state that Boolean properties should reflect assertions about the receiver, so in Swift one would expect:

  class Foo {
    var isEnabled: Bool // good
  }

rather than

  class Foo {
    var enabled: Bool // not Swifty
  }

When the property is @objc, e.g.,

  class Foo : NSObject {
    @objc var isEnabled: Bool
  }

The resulting Objective-C property doesn’t follow the Cocoa guidelines for Objective-C <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284-BAJGIIJE>:

  @property (readwrite,nonatomic) BOOL isEnabled;

because those guidelines state that properties do not use the “is” prefix.

My proposal is to strip the “is” prefix from the Objective-C name, but leave it off the getter, e.g.,

  @property (readwrite,nonatomic,getter=isEnabled) BOOL enabled;

The change would have no effect on the Swift name; it will only affect the Objective-C property name and setter name.

Thoughts?

  - Doug

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


(Angelo Villegas) #8

Initialising a getter for a Boolean property is the default behaviour so a
+1 vote from me.

- Angelo

···

On Wed, 24 Feb 2016 at 4:43 PM Radosław Pietruszewski < swift-evolution@swift.org> wrote:

Seems like an easy win, so I’m leaning towards a +1.

OTOH, are there any other cases where Swift -> ObjC automatically changes
names of things to optimize for ObjC? If we don’t do more of that (the '"Add
needless words" to Objective-C method names’ thread, or other quick wins
like this one), it would be weird to make just this one exception, a single
special case. I fear this would be more surprising than not changing
anything at all.

— Radek

On 23 Feb 2016, at 22:00, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote:

Hi all,

The Swift API guidelines state that Boolean properties should reflect
assertions about the receiver, so in Swift one would expect:

class Foo {
  var isEnabled: Bool // good
}

rather than

class Foo {
  var enabled: Bool // not Swifty
}

When the property is @objc, e.g.,

class Foo : NSObject {
  @objc var isEnabled: Bool
}

The resulting Objective-C property doesn’t follow the Cocoa guidelines
for Objective-C
<https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284-BAJGIIJE>
:

@property (readwrite,nonatomic) BOOL isEnabled;

because those guidelines state that properties do not use the “is” prefix.

My proposal is to strip the “is” prefix from the Objective-C name, but
leave it off the getter, e.g.,

@property (readwrite,nonatomic,getter=isEnabled) BOOL enabled;

The change would have no effect on the Swift name; it will only affect the
Objective-C property name and setter name.

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


(Radek Pietruszewski) #9

Ah, didn’t realize this.

+1 then.

— Radek

···

On 24 Feb 2016, at 17:31, Douglas Gregor <dgregor@apple.com> wrote:

On Feb 24, 2016, at 12:36 AM, Radosław Pietruszewski <radexpl@gmail.com <mailto:radexpl@gmail.com>> wrote:

Seems like an easy win, so I’m leaning towards a +1.

OTOH, are there any other cases where Swift -> ObjC automatically changes names of things to optimize for ObjC? If we don’t do more of that (the '"Add needless words" to Objective-C method names’ thread, or other quick wins like this one), it would be weird to make just this one exception, a single special case. I fear this would be more surprising than not changing anything at all.

We do a bunch of this already. We join the first argument label to the base name to form the first selector piece, inserting “with” if there’s no preposition in between already, and for throwing methods we either add “error:” in the appropriate place or append “AndReturnError” to the first selector piece if there are no other parameters.

  - Doug

— Radek

On 23 Feb 2016, at 22:00, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

The Swift API guidelines state that Boolean properties should reflect assertions about the receiver, so in Swift one would expect:

  class Foo {
    var isEnabled: Bool // good
  }

rather than

  class Foo {
    var enabled: Bool // not Swifty
  }

When the property is @objc, e.g.,

  class Foo : NSObject {
    @objc var isEnabled: Bool
  }

The resulting Objective-C property doesn’t follow the Cocoa guidelines for Objective-C <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284-BAJGIIJE>:

  @property (readwrite,nonatomic) BOOL isEnabled;

because those guidelines state that properties do not use the “is” prefix.

My proposal is to strip the “is” prefix from the Objective-C name, but leave it off the getter, e.g.,

  @property (readwrite,nonatomic,getter=isEnabled) BOOL enabled;

The change would have no effect on the Swift name; it will only affect the Objective-C property name and setter name.

Thoughts?

  - Doug

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


(TJ Usiyan) #10

+1

···

On Wed, Feb 24, 2016 at 11:45 AM, Radosław Pietruszewski < swift-evolution@swift.org> wrote:

Ah, didn’t realize this.

+1 then.

— Radek

On 24 Feb 2016, at 17:31, Douglas Gregor <dgregor@apple.com> wrote:

On Feb 24, 2016, at 12:36 AM, Radosław Pietruszewski <radexpl@gmail.com> > wrote:

Seems like an easy win, so I’m leaning towards a +1.

OTOH, are there any other cases where Swift -> ObjC automatically changes
names of things to optimize for ObjC? If we don’t do more of that (the '"Add
needless words" to Objective-C method names’ thread, or other quick wins
like this one), it would be weird to make just this one exception, a single
special case. I fear this would be more surprising than not changing
anything at all.

We do a bunch of this already. We join the first argument label to the
base name to form the first selector piece, inserting “with” if there’s no
preposition in between already, and for throwing methods we either add
“error:” in the appropriate place or append “AndReturnError” to the first
selector piece if there are no other parameters.

- Doug

— Radek

On 23 Feb 2016, at 22:00, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote:

Hi all,

The Swift API guidelines state that Boolean properties should reflect
assertions about the receiver, so in Swift one would expect:

class Foo {
  var isEnabled: Bool // good
}

rather than

class Foo {
  var enabled: Bool // not Swifty
}

When the property is @objc, e.g.,

class Foo : NSObject {
  @objc var isEnabled: Bool
}

The resulting Objective-C property doesn’t follow the Cocoa guidelines
for Objective-C
<https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284-BAJGIIJE>
:

@property (readwrite,nonatomic) BOOL isEnabled;

because those guidelines state that properties do not use the “is” prefix.

My proposal is to strip the “is” prefix from the Objective-C name, but
leave it off the getter, e.g.,

@property (readwrite,nonatomic,getter=isEnabled) BOOL enabled;

The change would have no effect on the Swift name; it will only affect the
Objective-C property name and setter name.

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