4

For ObjC, I have the choice to use either dot notation or square bracket notation. Is there a way to enforce (with errors/warnings) a certain notation for uniform notation throughout a project?

Raildex
  • 3,406
  • 1
  • 18
  • 42
  • 1
    care to elaborate why my question is downvoted? The question is on-topic in my opinion as of `software tools commonly used by programmers;` – Raildex Nov 24 '19 at 13:38

1 Answers1

4

Perfectly valid question. Not sure why the downvotes.

When we designed @property, the dot came along with it. There was considerable debate about whether the dot should be limited to @property or not. We landed on "not" because there was too much pre-existing API that kinda sorta felt like a property but would never be re-declared as an @property because it really wasn't.

NSArray's -count is an obvious one. That could easily be @property. But then there are methods that fall more into the gray area.

Didn't seem like there was enough value to really warrant enforcing such a rule, hence . was presented as (nearly) identical with calling a getter or setter.

The compiler didn't have an option to enforce one or the other then. And I'm pretty darned sure-- but not 100% certain-- it hasn't grown one since.

bbum
  • 162,346
  • 23
  • 271
  • 359
  • Thank you. Although I didn't mean a compiler error/warning, but an IDE (since I am using AppCode, see the tags of the question) warning/error. – Raildex Nov 25 '19 at 12:10
  • 1
    @Raildex There is no difference; The errors/warnings you see in the IDE are entirely produced by the compiler. – bbum Nov 26 '19 at 17:27
  • Actually, AppCode has its own "inspections" that can report additional warnings and errors. But there is indeed no inspection for this case. Normally, I'd encourage you to file a feature request, but ObjC-specific features will not be a high priority at the moment. – nschum Dec 04 '19 at 21:53