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

Douglas_Gregor · 2016-02-23 21:00:01 UTC

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

jrose · 2016-02-23 21:10:11 UTC

+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

dabrahams · 2016-02-23 22:25:32 UTC

+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

SlaunchaMan · 2016-02-23 21:02:26 UTC

+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 · 2016-02-24 08:36:05 UTC

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 · 2016-02-23 23:07:45 UTC

+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 · 2016-02-24 16:31:31 UTC

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 · 2016-02-24 08:58:49 UTC

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 · 2016-02-24 16:45:00 UTC

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

griotspeak · 2016-02-25 02:05:10 UTC

+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