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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 bothUIColor
'sorangeColor
and andUIApplication
'ssharedApplication
are true properties: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 thatsharedApplication
, 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:
README….md
, changed the “For example:” code sample to useUIColor.orangeColor
&UIApplication.sharedApplication
, and changed the “Not:” code sample to use[UIColor orangeColor]
&[UIApplication sharedApplication]
.