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.
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.