I very much agree, but saying it in such a way won't help others to understand that. That is persons that haven't understood the significant difference right now.
I would be interested in why it is considered a terrible practice.
That it's slow might be a good point but for performance critical stuff I use D and for larger web project Ruby on Rails (where performance is a whole different topic). PHP is my tool of choice for small and compact web projects and since I try to keep them as simple as possible performance isn't that much of a concern. Anyway I did a small benchmark and was a bit surprised:
direct access: 0.276369s
getter access: 0.540416s
property overloading access: 0.825164s
Of course I can publish the benchmark source if someone is interested. It basically accesses a property 1000000 times adds the returned value to a sum (so that it's not optimized away… just in case).
The overhead looks ok for me. 1 out of 5 properties can be redirected via property overloading before its performance is worse than getter methods. I don't really know much about the internals of large PHP projects but I you can avoid most "empty" getter and setter methods and handle the view exceptions with property overloading performance seems fine for me.
Unexpected behavior might be a problem. However not existing properties still return NULL. The only difference is that no notice is generated… and that can be easily done with one line at the end of the __get() and __set() functions. Management of "raw" property overloading can be troublesome for a larger number of properties. However you can simply add some runtime reflection to call a corresponding getter function. But in that case I would start to think about the interface and if I might have done something wrong (in regards to encapsulation).
Having spend much time in the Ruby world I really like the kind of interfaces you can build with property overloading (like SimpleXML). For me more fluid handling like that is worth the performance cost.
The example is the most simple way I could think of. It should only show that is is possible not what is the perfect solution (if there is any).
Of course you could throw in some runtime reflection and variable function calls to make it more maintainable. However for me it needs to pay of… I don't want to maintain such a system for just a hand full of properties. I like to keep complexity "flat" and so I often stick to the direct language features. But on large projects the code you linked could really come in handy. Thanks. :)
I agree that getters and setters aren't object oriented. It was the whole point of my blog post to make people think about that. It wasn't written for people who already understand that, though… otherwise it would be quite a bit shorter. ;)
The sad thing is that way to much people think "getters and setters" when they hear "object orientation". Maybe even "Eclipse will do that for me". Needless to say that encapsulation isn't understood then, too. But encapsulation is bigger topic of it's own and would have been to much for that post.
While talking about that with other people I got the impression that just explaining the way it was meant to be does not work well. Especially if a professor and many books tell otherwise. Therefore I try to make people think for their own about the problem. Showing the problem, how it is solved and how it can be solved in other situations. I don't know if I succeeded in that.