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

Douglas_Gregor · February 23, 2016, 9:00pm

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 <Naming Properties and Data Types

@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 · February 23, 2016, 9:10pm

+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 <Naming Properties and Data Types

  @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 · February 23, 2016, 10:25pm

+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 · February 23, 2016, 9:02pm

+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
<Naming Properties and Data Types;
:

@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 · February 24, 2016, 8:36am

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 · February 23, 2016, 11:07pm

+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 · February 24, 2016, 4:31pm

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 <Naming Properties and Data Types

  @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

anjerodesu · February 24, 2016, 8:58am

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
<Naming Properties and Data Types;
:

@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 · February 24, 2016, 4:45pm

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 <Naming Properties and Data Types

  @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 · February 25, 2016, 2:05am

+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