I would agree that this is true, but I’m not sure how much of the credit belongs to ObjC and how much belongs to Cocoa. There quite simply is not anything as good for desktop development on any platform as Cocoa - the only thing that comes even close in my mind is gtkmm/gnomemm (C++), and it doesn’t have nearly the scope of Cocoa - not to mention the fact that Unix still isn’t much of a target for ISV-built desktop software.

(Of course perhaps it is only possible for Cocoa to be so good because it is implemented in ObjC)

The comments herein assume that the properties feature, and in particular the syntax, follows something akin to that described here: here.

It’s difficult to know where to start to critique such an ill-informed and misrepresentative diatribe. To take on a couple of aspects:

No, synthesized accessors and setters are cool, properties are not.

This suggests a fundamental misunderstanding of the technology. Synthesised getters and setters are a primary feature of properties. The quoted sentence thus simply doesn’t make sense.

Accessing the property goes through KVC,

It’s not clear why you make that assertion. If as appears to be the case you intend to imply that
anObject.property
is compiled to become
[anObject valueForKey:@"property"];
then perhaps you could provide some evidence to show why you believe this to be true?
Fundamentally, however, properties and key-value coding are orthogonal technologies.

To address a comment from l0ne:

I agree that this sucks. Having -ivar and -setIvar: would have been better. Maybe there are folks at Apple who are tired of all those “[” and “]”s?

This again simply doesn’t make sense. Using properties, you’re still free to use -ivar and -setIvar if you choose.

To return to the original text, the biggest irony comes right at the end:

explicit is better than implicit
So, where do Objective-C properties fit in?

A significant aspect of the properties feature is precisely that it makes information explicit. By looking at a header file you will quickly be able to tell that a particular instance variable is considered a property of an object, that assigned values are copied as opposed to retained,and so on.

Properties supports a much more declarative style of programming. The intent is made explicit. This is of benefit not just to the originator of the code (who reaps the benefit of a considerable reduction in code size) but also of the consumer who can see immediately the properties that a class has and in turn what attributes and behaviours those properties themselves have.

Stepping back, your primary objection to properties seems really to be with the dot syntax, not the feature itself. If that’s the case, then you’re perfectly free to continue using square brackets whilst still leveraging the other conveniences the feature provides.

There’s also that object.property is moving away from Objective-C’s Smalltalk roots. We’re thinking about things as data structures rather than live objects which respond to messages.

Cocoa has used key paths for a long time, and they took on a more prominent role in Cocoa Bindings and Core Data. Maybe dots suggest data structures by C conventions, but I think Cocoa programmers are smart enough to learn that they can mean messages in Objective-C 2.0.

Go. File it now.

And I love the quirk of it, too.

The advantages of using proper old-school accessor methods are as you mention them, and there is little reason for properties to exist, but for me it just feels better to use the Smalltalk-style format.

At least, this sounds much like what I’d do.

I agree that this sucks. Having -ivar and -setIvar: would have been better. Maybe there are folks at Apple who are tired of all those “[” and “]”s?

x.y refers to a C struct field, nothing else.

now i’ll spend my time looking at the header file to determine if x is a struct or an object…
thanks apple.