the very nice aspect of Objective-C was its readability . Maybe you want convenience, but I just see useless addition and more and more lost of objective-C.

@countach

on the contrary! Objective-c is an elegant extension to C. and C compatibility is still a great asset. You can link to whatever c library you need. Don’t ask more changes which bring nothings to improve applications.

and C is not a “legacy cruft”, you can see the runtime allow objective C to be completely dynamical. I cannot fathom why “c” can bother you.

it’s a tool, and the important quality for a tool is to be easy to use.

I don’t agree that it makes code brittle. It could, but it all depends on the circumstance.

Since Objective-c is a hack on a hack on a hack, its hard to get too excited about ruining the purity of the language. I think they should redesign the language from the ground up with the same semantics (for backwards compatibility) but a whole new syntax, abandoning the legacy cruft of C. Whether it becomes even more like Smalltalk, or more like Java wouldn’t matter.

Your example:

someObject.someProperty.someOtherProperty.yetAnotherProperty = 42;

is EXACTLY why I agree with the cimgf article that the dot syntax is not a good thing. The example is a pretty bad violation of the ‘Law of Demeter’ (see http://c2.com/cgi/wiki?LawOfDemeter). The fact that the bracket syntax version of your example looks ugly is a clue to anyone reading the code that something is wrong. The dot syntax goes some way to masking this. The ugliness of the nested bracket case is what some refer to as a ‘Code Smell’ (see http://c2.com/xp/CodeSmell.html).

If you are routinely nesting the sending of messages to the results of messages as deeply as in your example, you may want to reexamine your coding style, as this ends up creating dangerously brittle code.

Say you have a property like this:

@property(copy) NSString *message;

And you use it like this:

self.message = @”Hello, world!”;

That use of the “message” property will compile exactly the same as this Objective-C 1.0 code:

[self setMessage:@"Hello, world!"];

There is NO difference between dot syntax and bracket syntax in terms of the generated code. Therefore, there is NO difference in how property use behaves.

I’m not sure why people have been assuming that dot syntax behaves like key-value coding, but it doesn’t. It’s just a different way of sending a message. There aren’t even objc_setProperty or objc_getProperty calls that dot syntax compiles to – dot syntax actually compiles to invocations of objc_msgSend, just as bracket syntax does.

I don’t understand why knowing if something is a struct or an object is necessary. If every struct in Cocoa became a proper object overnight, and via dot-syntax all code that used them still worked… what would be the loss? (From a programmer’s perspective; not judging by the performance of the machine). I have never defined a struct in any Obj-C code I have written. I just don’t see what they add over objects, and they don’t play nice with Cocoa containers, so I avoid them. What I’m trying to say is, “yes, dot-syntax hides a bit of type information .. so what? I don’t see how that hides the intent of code.”

Your probably not abrasive enough for people to throw strawman arguments at you :)

Either that or I am hanging out in the wrong places.

Could be both…

I do have to say. I really like halving the line count of my dealloc method by using self.foo = NULL; so much easier to scan.

That makes the eyes bleed!

Those are all myths that I have heard recently within the last couple of months!

Well yeah it is syntactic sugar. But I for one am a big fan of syntactic sugar. It makes my work day (*) more pleasant. I don’t have to care about balancing the braces in:

[[[someObject someProperty] someOtherProperty] setYetAnotherProperty:42];

I can just very explicitly:

someObject.someProperty.someOtherProperty.yetAnotherProperty = 42;

If part of that property path changes I can merely add or remove atoms as needed. No balancing braces. I hate balancing braces. Don’t you?

And as for maintainability, I really don’t think either is necessarily more or less maintainable than another. When I think software maintenance I think about software complexity, not details of syntax. In fact I’d say that most if not all syntactic sugar by its very definition reduces complexity and therefore might contribute to ease of maintenance?

Also don’t forget that the foo/setFoo convention is just that, a convention. And a convention often ignored, for example -[NSSet setByAddingObject:]. Oops!

People tend to poo over syntactic sugar. If I had a penny for every time I heard the phrase “oh that’s just syntactic sugar” I’d be knee deep in hookers and blow right now. Honest. But a lot of language features we take for granted are just syntactic sugars. Hell the C array syntax is a classic example of syntax sugar. Hell isn’t Objective-C just one big syntactical sugar on top of objc_msgSend? Amiright?

So yeah, there are issues with Objective-C’s dot notation. Namely the handling of arrays. MyObject.frame.origin.x just can’t be done and you’re struct with [MyObject frame].origin.x (see what I did there?) and need to be careful when assigning to struct members. That’s a flaw. I grant you. But in practice it is one that is easily understand and avoided after you use dot notation for a while.

But the nice thing is, you don’t have to use it. The language is happy with both styles. Use whatever makes that inner geek happy. I’ll be using dot notation because it makes mine happy.

I seem to recall that when the syntax was first announced at WWDC (2007? 2006?) it was explicitly described as helping to make the language more accessible to people familiar with Python and Ruby. They’re probably in a similar boat, where they’d (correctly, in their case) just assume it was an object anyway and therefore not suffer any confusion.

But regarding those “myths”: Does anyone think those are true? I don’t think I’ve encountered those mistaken ideas before. Maybe I just “get” how they work because, since I knew Objective C already, I paid close attention to what exactly was implied by the new syntax and therefore avoided potholes that might trap the unwary.

Then I curse the language, the developer tools, the platform, Steve Jobs, this blog, and then walk away waggling my head smugly knowing I’m superior for having used anything else before this.