I came across this post explaining php magic methods and was surprised on the cautionary comments about using magic methods on static functions.
Is anyone able to explain why this is in a way I can understand?
Part of me thinks the author of that post is confused, as he got what I would have saw as the intended output (per the manual).
The purpose of __callStatic and __call are to be able to call otherwise inaccessible methods/properties dynamically. Since he called the methods using the instantiated process, it used __call (because that is for instantiated calls. When he used the static representation, it called __callStatic, seems correct to me.
Morale of the story is, he wanted to call a method anonymously and have PHP discover whether it needed to be called using instantiation or a static call. That isn’t realistic if you ask me. You should know whether or not the method you want to access is instantiated or static and use the correct representation accordingly.
So unless I don’t fully understand the problem, I think PHP dealt with it correctly.
Ok, I initially found a reference to it ( __callStatic ) in this post:
http://vanillaforums.org/docs/plugins
And then after reading that it seems he isn’t the only one drawing that conclusion.
However the poster in the first post seemed to suggest it was working correctly in 5.3.3 and then the “fix” was rolled back out because of backward compatibility issues.
Maybe no one is prepared to touch that ( __callStatic ) now because of the controversy.
First things first: (emphasis mine)
I would have liked it if there were no functions in Garden. In my mind, functions should be in a class even if it is a static utility class that refers to the methods just like you would if they were functions. However, when I started writing Garden (and still today), PHP was lacking some things that I think would be necessary in order to put functions into a static utility class. For example, __callStatic isn’t production-ready, yet. So there would be no way to override functions if they were in a static class.
Note the last part of that statement. The initial document you linked to, didn’t use a static class, so therefore, it would stand to reason, he wasn’t using it properly or as intended. But rather wanted PHP to figure out how to call it (statically or via instantiation, and that isn’t PHP’s role).
I’m not going to even guess at what happened in 5.3.3, other than it seems whatever they did, broke something else from its intended purpose. In trying to let PHP figure out how to call the method, it resulted in more things breaking than actual resolution of an edge case. PHP should not be in charge of determining how to call method. You should know whether it is in a static class or an instantiated class. If you don’t, then you need to figure it out before attempting to call it.
Also, it seems you can utilize the Reflection API in PHP 5 to determine if a class is static or instantiated, so it also stands to reason, if he wanted __callStatic to be used properly he could have verified that the classes were indeed static before hand so he could use the static representation so it would call correctly.
http://stackoverflow.com/questions/123718/php-check-if-a-static-class-is-declared
After seeing this though, I have to wonder why internally PHP couldn’t utilize that logic to make the appropriate call… The likely answer is, performance. Reflection usually results in a performance hit, so chances are the cost was significant enough to be noticed and thus didn’t make sense to do.