Does Objective-C Really Need Properties?

Continuing on my series of articles along the theme of “does x really need to exist?”, I speculate about the new property syntax in Objective-C 2.0. For those without context:

  • In Objective-C 2, you’ll be able to do object.property
  • Accessing the property goes through KVC, so compliant methods or direct ivar access are used as appropriate
  • Properties have metadata; different kinds of properties are available, including custom getter and setter names
  • For ivars which you are too lazy to write KVC-compliant methods, you can have the compiler synthesize (!) them for you (and man am I lazy)

It sounds pretty fancy and high-tech. But as I expand my horizons lately I came across the documentation on property access in Python:

For objects, the machinery is in object.__getattribute__ which transforms b.x into type(b).__dict__[’x'].__get__(b, type(b)). The implementation works through a precedence chain that gives data descriptors priority over instance variables, instance variables priority over non-data descriptors, and assigns lowest priority to __getattr__ if provided.

Say what? I’m still pretty much a Python novice but those rules sound pretty arcane. But turn this around and try to explain Objective-C 2 properties to someone else; I’m sure the rules are at least as arcane-sounding as the Python implementation, and to boot, KVC-compliant methods have side effects because of KVO. So really, what does:

x.foo = y;

…do? Nevermind that from just that line you can’t tell me if that’s a C struct and we’re generating a simple store opcode or if it’s an Objective-C object and we’re generating, and triggering, the equivalent of hundreds of lines of C code. I mean, answer me this: from just that line of code, about how long should that code take to execute? You mean it might take a lock and update a NSTextField? Hells yeah, this is one crazy programming environment, and it’s only because in general Cocoa is so good that we trust these kinds of things.

Woah, properties are cool, you shouldn’t say that they suck

No, synthesized accessors and setters are cool, properties are not. The property syntax sucks rocks, and even the concept sucks rocks. What is it? Is it an ivar? A proxy for another object’s ivar (because it could be)? Is it the return value of a method? Because if it is, why are we doing object.property instead of [object property]?

What it really is is just questionable syntactic sugar which burns like acid in my mouth. What if we took all of the ideas introduced with properties and just said: “hey, if you don’t write -[Object ivarName] and -[Object setIvarName:], we’ll synthesize proper KVC methods for you.” “Pretty sweet,” I’d say. You’ve just saved me just as many lines of code as were demonstrated using the Delete key at WWDC this year, but you haven’t introduced any weird ambiguous syntax.

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. Tell me: which is clearer, a) a data access which you can override with a method that accesses some other data or generates a method call which may call other methods depending on whether or not they’ve registered interest in changes to your “data” (which may not really exist); or b) just calling everything a method call in the first place?

I just get this feeling that Objective-C 2 (in this respect) is trying to be something it’s not. It’s not a 4GL; it’s a language which sits at the intersection between message sends and function pointers. It’s a strict superset of C; at one point in time, it added a dynamic OO programming system to ANSI C using only 18 keywords. And these qualities of the language are what gives it its unnatural power, given that it’s (was?) just such a simple extension to the C language. It is a language which empowers the desktop software developer to do the work of six C++ engineers and still have time for a Vespa ride and a cappuccino after lunch. And it does this by staying lean, by integrating with outside code, by keeping the rulebook to something concise.

But it’s not ECMAScript, nor is it Python, nor is it Ruby. You want to use those languages? Bridges exist. Bridges exist because the Objective-C runtime is so simple and accessible — something that I fear parts of this Objective-C 2 initiative will change. To take a mantra from the Python world:

explicit is better than implicit

So, where do Objective-C properties fit in?

About this entry

You’re currently reading “ Does Objective-C Really Need Properties? ,” an entry on stuffonfire.com

Published:
12.8.06 / 5am
Category:
Programming