Google published a set of tips on how to increase the performance of PHP a while ago under the heading "Let's make the web faster". I recently came across the article again, and it's been changed a lot since last summer when it was published. At that time, a number of the tips were massively criticized - a lot of blog posts were written, comments made, etc. Seemingly, this has led to the article being changed, which is good, as some of the info on it previously was rather misleading. Most of what is left is alright, although one or two of those that have been allowed to stay are still dubious:

Don't copy variables for no reason

Sometimes PHP novices attempt to make their code "cleaner" by copying predefined variables to variables with shorter names before working with them. What this actually results in is doubled memory consumption (when the variable is altered), and therefore, slow scripts. In the following example, if a user had inserted 512KB worth of characters into a textarea field. This implementation would result in nearly 1MB of memory being used.

Although the above statement is correct (due to the 'when the variable is altered' which I'm presuming has been added later) the example that succeeds it does not in any way double the memory used. The example copies a variable and then echoes the copy - which doesn't amount to a change and hence won't actually create a copy of the variable. It would be nice to see the whole text revised instead of a bit of extra info inserted in a parenthesis ... oh well.

However, that's not the main point that struck me as odd. No, what got me paying attention is this bit:

Avoid writing naive setters and getters

When writing classes in PHP, you can save time and speed up your scripts by working with object properties directly, rather than writing naive setters and getters. In the following example, thedog class uses the setName() and getName() methods for accessing the name property.

Then follows an example with a class with public(!) properties and get/set methods. And of course the tip of not using getters and setters like that. However, is that really the tip that one should give programmers? What happened to encapsulation? Not to mention: who would ever write getter and setter functions for public properties?

In the theoretical world that people are being taught, you're told that keeping properties offlimits to the outside world is a good thing: it limits the knowledge the world can possibly have of your object and hence minimizes the chance for tight coupling due to someone figuring out that \$obj->property is possible and easier than \$obj->getProperty(). Why are people being told this? Because when later down the line you realise that you have to change obj::\$property to obj::\$some_other_property, you'll wish you never had the bright idea of making use of public properties. Specifically, going through code in many different places changing \$obj->property to \$obj->some_other_property really makes you annoyed ... there are much better ways to spend your time.

Of course, there's an alternative to fixing references to obj::\$property. It's called __get(), it's a magic method, and it's muchslower than setter/getter functions. In other words, using the hint from Google - which is supposed to speed up your apps - you're implicitly going down the road of tight coupling. Which means that:

Setting and calling the name property directly can run up to 100% faster, as well as cutting down on development time.

is a typical short-term view of things. Sure, development time is shorter if you don't have to write the ten extra lines of code for getters and setters, but development time is massively extended when you have to refactor your code to not use public properties any more. Not to mention that if you the mitigate that with __get() your code suddenly won't run up to 100% faster but more likely 100% slower (the code dealing with these properties, that is).

What should you do? You should design your objects properly, is what you should do. If some properties are core to the object and don't need a check when being set, then obviously you can go without getters and setters. However, if you're looking at an object that might change in the future or if you're dealing with properties that should be validated before being set (failing early is often better than failing late) or if you just want to minimize the signature of the object, then use setters and getters.