Skip to content
This repository has been archived by the owner on May 9, 2023. It is now read-only.

Updated dot notation syntax to use dot-notation for all properties (in latest API) #178

Merged
merged 1 commit into from
Aug 15, 2018

Conversation

capnslipp
Copy link

Updated the code sample for the Dot Notation Syntax section to use dot-notation syntax for all properties in the latest API.  As a result, changed some (correct) usage of dot-notation syntax in the “Not:” code sample to use square-bracket syntax, for clarity.

The reason behind these code samples originally having square-bracket syntax for some calls in the “For example:” sample and dot-notation syntax for those calls in the “Not:” sample was that formerly, all class-level getters in Obj-C were just plain methods.  That changed in Xcode 8 (and continues in the current iOS/macOS API as of Xcode 9.4.1 and the latest Xcode 10 beta) with the introduction of class-level properties in Objective-C, and the consequent updating of the iOS/macOS APIs by Apple.  Now both UIColor's orangeColor and and UIApplication's sharedApplication are true properties:

// From the macOS SDK documentation that ships with Xcode 8.4.1:

@property(class, strong, readonly) NSColor *orangeColor;

@property(class, nonatomic, readonly) UIApplication *sharedApplication;

While it could be understandable that NYTimes might want to keep calls to things like [UIApplication sharedApplication] using square-bracket syntax for consistency with their/your existing codebase, that causes a problem for potential new Obj-C programmers using your guide to help them learn Obj-C, since they'll read “Dot notation is RECOMMENDED […] for getting […] properties” but then check the official Obj-C docs and see that sharedApplication, leading to confusion over the apparent non-sensical nature of your style guide.  It doesn't help that Dot Notation Syntax is the very first section in the style guide, and could turn off new programmers to the validity of your style guide (despite the fact that a few years ago for Xcode ≤7, the style guide was accurate).

So in summary, I believe it makes sense to update code samples to use dot-notation syntax where Apple has updated the iOS/macOS APIs to use properties.  Even in an era of Swift, Obj-C is still receiving updates and consistency clean-up by Apple — which is a wonderful thing for us long-time Obj-C devs — and so it makes sense to embrace that.

Changes made:

  • In the Dot Notation Syntax section of each translated README….md, changed the “For example:” code sample to use UIColor.orangeColor & UIApplication.sharedApplication, and changed the “Not:” code sample to use [UIColor orangeColor] & [UIApplication sharedApplication].

…n latest API)

Updated the code sample for the **Dot Notation Syntax** section to use dot-notation syntax for all properties in the latest API.  As a result, changed some (correct) usage of dot-notation syntax in the _“Not:”_ code sample to use square-bracket syntax, for clarity.

The reason behind these code samples originally having square-bracket syntax for some calls in the _“For example:”_ sample and dot-notation syntax for those calls in the _“Not:”_ sample was that formerly, all class-level getters in Obj-C were just plain methods.  That changed in Xcode 8 _(and continues in the current iOS/macOS API as of Xcode 9.4.1 and the latest Xcode 10 beta)_ with the introduction of `class`-level properties in Objective-C, and the consequent updating of the iOS/macOS APIs by Apple.  Now both `UIColor`'s `orangeColor` and and `UIApplication`'s `sharedApplication` are true properties:

```objc
// From the macOS SDK documentation that ships with Xcode 8.4.1:

@Property(class, strong, readonly) NSColor *orangeColor;

@Property(class, nonatomic, readonly) UIApplication *sharedApplication;
```
While it could be understandable that NYTimes might want to keep calls to things like `[UIApplication sharedApplication]` using square-bracket syntax for consistency with their/your existing codebase, that causes a problem for potential new Obj-C programmers using your guide to help them learn Obj-C, since they'll read _“Dot notation is RECOMMENDED […] for getting […] properties”_ but then check the official Obj-C docs and see that `sharedApplication`, leading to confusion over the apparent non-sensical nature of your style guide.  It doesn't help that **Dot Notation Syntax** is the very first section in the style guide, and could turn off new programmers to the validity of your style guide _(despite the fact that a few years ago for Xcode ≤7, the style guide was accurate)_.

So in summary, I believe it makes sense to update code samples to use dot-notation syntax where Apple has updated the iOS/macOS APIs to use properties.  Even in an era of Swift, Obj-C is still receiving updates and consistency clean-up by Apple — _which is a wonderful thing for us long-time Obj-C devs_ — and so it makes sense to embrace that.

Changes made:

* In the **Dot Notation Syntax** section of each translated `README….md`, changed the _“For example:”_ code sample to use `UIColor.orangeColor` & `UIApplication.sharedApplication`, and changed the _“Not:”_ code sample to use `[UIColor orangeColor]` & `[UIApplication sharedApplication]`.
@capnslipp
Copy link
Author

Forgot to mention this is the commit message: A nice rundown of the addition of class properties to Obj-C can be found at Use Your Loaf's Objective-C Class Properties blog post.

@loganmoseley
Copy link
Contributor

Excellent suggestion and write-up. Dot-notation is indeed how I at least would write ObjC now. Thanks for contributing!

(Somebody else here will have to merge.)

@mbbischoff
Copy link
Contributor

Great PR! I agree that this should be merged ASAP.

@Veronique
Copy link
Contributor

Agreed.

@Veronique Veronique merged commit 8b17c1c into nytimes:master Aug 15, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants