Hi, I have to agree with Quincey here.
Quincey Morris wrote: > 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. If your code consists of a bunch of objects containing structs, then you would not be very wise to use dot syntax. This all comes down to coding standards as well. If you follow one, any syntax can become helpful and manageable. If you don't, then problems like the above (as well as many, many others unrelated to the basic language syntax) will bite you where it hurts. > 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. I found in my own code, that something like this (which becomes all-too-common when using core data and array controllers or anything like it): [[[obj thing] anotherThing] setThird:[obj3 thirdthing]]; is far less clear (and thus causes worse obfuscation) than: obj.thing.anotherThing.third = obj3.thirdthing; To be clear: I designed my code so that there is absolutely no chance of ambiguity between properties and structs, and I also follow a coding convention that means I only use dot syntax for simple properties, and otherwise use bracketed method calls, as Quincey describes. I mention this because when I was first using Objective C, coming from a C background, I saw the dot syntax as equally evil for the reasons you gave. However, it wasn't long before I was seeing bugs *caused* by not using dot syntax, where I was putting brackets around the wrong thing by accident, and getting weird errors, as well as having extreme difficulty figuring out what a line of code even did, slowing development time considerably. Greg _______________________________________________ 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
