Yes, I reckon you should generally use parentheses.
When ASObjC was born, there was no such thing as an Objective-C property – everything was done with accessors, as in -someProperty
and -(xxx)setSomeProperty:
. In fact, Objective-C properties are really a syntactical sleight of hand – the same old stuff is happening behind the scenes. (Where the “same old stuff” includes all the memory management stuff that used to be a pain to write in accessors.)
For reasons to do with Automatic Reference Counting and Swift, nearly every method that takes no parameters has been replaced by an equivalently named property. (This has been the cause of lots of odd documentation errors in terms of when things were first made available.)
Anyway, if you use parentheses, ASObjC uses the accessors. If you don’t use parentheses, ASObjC uses key-value coding: it’s exactly the same as using valueForKey:
.
What’s the practical difference? Using the accessors, ASObjC uses the method signature as the basis for bridging results. Using KVC, the results are handled according to the KVC rules. So consider this:
aString's |length|()
The scripting bridge will see that length
is defined as returning an NSUInteger, and converts the result to the nearest AS equivalent, an integer.
Now consider this:
aString's |length|
In this case there’s no referencing the method or property signature, and KVC always returns results as objects, packing them as necessary. So this time the result is an NSNumber.
In cases like defaultUserNotificationCenter
, where the result would not be bridged anyway, there’s no difference. But otherwise it’s the sort of subtlety that can make trouble-shooting a fun business.
The other practical point is that, apart from one case I’ve come across, including the parentheses always works, whereas I’ve seen quite a lot of cases where leaving them off results in failure.
And of course syntax-coloring of methods is lost without parens, which I personally find makes code harder to read.