On Feb 20, 2009, at 16:17, Erik Buck wrote:
What is the redeeming value of the Objective-C 2.0 properties dot
syntax ?
I don't get it. I see lots of posts from other people who don't get
it. Who does get it ?
OK, I'll bite, though there is of course no good outcome to a
discussion like this. I can't say whether I "get" it, but I certainly
use it.
I think dot syntax makes obfuscates code. When I read such code, I
don't know which statements evaluate to pointers and which evaluate
to structures. Using dot syntax with pointers is a gross overloading
of the language operator.
It's an overloading of the operator. The "gross" part is a value
judgement and therefore indefensible or unarguable, depending on where
you're standing. The period in a floating point constant is *also*
similar to dot syntax (although not an operator). Presumably you don't
object to that, presumably because although it has a very local
ambiguity it's also very easy to disambiguate in context.
The re-use of symbolic tokens, in coding as well as real life, may
introduce formal ambiguity, but that's not automatically a fault and
is oftentimes an advantage. An *extra* argument is needed to conclude
that ambiguity == obfuscation, and such an argument is specific only
to the individual case.
What doe the following line of code do ?
myPerson.familyName = myPerson.father.familyName;
Prior to Objective-C 2.0, I would say the code set the familyName
member of the myPerson variable which is a structure or union.
After Objective-C 2.0, the above line could be equivalent to any of
the following:
[ myPerson setFamilyName:[[[myPerson father] familyName]];
myPerson.familyName = [myPerson.father familyName];
[ myPerson setFamilyName:[[myPerson father].familyName];
myPerson->familyName = [myPerson->father familyName];
myPerson->familyName = myPerson->father->familyName;
Without having prior intimate knowledge of all types involved, the
dot syntax above is ambiguous and certainly makes code reading much
more difficult.
It's only lexically ambiguous. You won't get very far trying to read
code syntactically (let alone semantically) without some longer range-
information, such as the approximate type (is it an object or not?) of
the symbols involved -- for reasons beyond disambiguation of dot syntax.
What is the counter argument ?
1. I type a lot of method calls. With dot syntax, I don't have to
think about balancing the braces. Similarly, I don't have to worry
about capitalizing the property name for a setXxxx method call. These
are very small advantages, of course, but tangible (to me).
2. I find it far more useful to distinguish verbs (actions) from
adjectives (attributes) applying to objects than to distinguish
objects from structs. Having 2 syntactic forms for method calls allows
me to make the more-useful (to me) distinction. (Yes, I know that
properties are "really" verbs, but the fiction that they're adjectival
is part of the usefulness.)
3. In code using Cocoa frameworks, I rarely have to use structs anyway
(apart from NSRect, NSPoint, etc, which are frequent enough to count
as a special case), so there's not much opportunity even to consider
whether a struct or an object is in play.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
