the heap

This is a kind of Seinfeld post in that it really has no point. I was going through some PHP code recently (a symfony tutorial) and found myself vexed by the way that properties in the example (and I assume in symfony overall) are implemented as function calls. For example, given an object, $o, with a property named foo, its accessor is a method named getFoo ($o->getFoo()) and it’s mutator is a method named setFoo ($o->setFoo($value)). It’s silly, but my preference is for properties to be syntactically distinct from methods – $o->getFoo() becomes $o->foo, and $o->setFoo($value) becomes $o->foo = $value.

In PHP, the origins of the setFoo/getFoo methods is probably rooted in older versions of the language where classes had no control over member access. Members were identified with the var keyword and were all effectively public. A useful workaround to separate public and private members was to implement getters and setters for those members that were public, and everything else was private. This was a decent solution, though property access was on the honor system: a user of the class could still reach in and directly modify a member value regardless of its intended visibility or whether it had accessor methods defined.

When PHP 5 came along, it introduced public, private and protected visibility specifiers so that classes could finally enforce encapsulation. In addition, the __get and __set magic methods were introduced. When a user of a class attempts to access a member that either doesn’t exist or isn’t visible in the current context, access is routed to these methods (if they’ve been defined). This has the benefit of allowing the class author to perform additional processing when a value is set – setting a dirty flag, validatng the new value, etc. – while still allowing the user of the class to use property syntax. The one downside that I can see here is that __get and __set must incur a slight performance penalty because it’s a last resort for locating the property value (the engine must have to check to see whether the property exists, then check to see whether it’s visible, and failing those checks, needs to check to see whether the appropriate magic method is available and then make the call), and then the methods themselves have to do processing to resolve the property name (passed as the first argument to both methods). I can’t see this being too significant, though, so it doesn’t bother me to use it.

I explain my preference for property syntax with the following points:

• separate syntax for property access vs. method calls carries the subtle implication that you are working with data rather than triggering an action (1)
• the origins of the set/get methods for property access feels obsolete
• $o->foo feels more elegant than $o->getFoo()
• property syntax lets you do $somevar = $o->foo = 100, a seldom-used C-ism (2)

1) Though it’s not guaranteed. I’ve seen classes where property access triggers an action (setting the connected property to true makes the connection, rather than call a connect() method. That feels more than dirty to me… almost evil.)
2) You can get the same result if your setFoo method returns the new value of the property.

Interestingly, while this is probably my general preference, I’m not married to it. For example, Objective-C only recently added dot notation for properties in version 2.0 of the language, and though it’s syntactically more in line with my preference for PHP, I prefer the old method.

Prior to version 2.0, property access was very similar to what we see with PHP… property setters and getters are implemented through class methods. Given an object, someObject, with a property named age, you access the property by sending the age message to the object: [someObject age]. To set the property, you send the setAge message: [someObject setAge: 25]. When Apple released version 2, they added support for familiar dot syntax: [someObject age] becomes someObject.age, and [someObject setAge: 25] becomes someObject.age = 25.

You’d have thought that I’d be all over the dot syntax, but I’m not. I couldn’t say for sure, but I think that it’s because the Objective-C convention for working with objects is to pass messages, and that the dot notation feels out of place.