Re: __call overload detection

Andrew Yochum wrote:

Consider a situation where a proxy/mediator/broker class implementing __call proxyies method calls to other classes (possibly of 3rd party origins), which themselves may or may not implement __call. You'd like the broker itself to have a consistent behavior for the sake of its users and good clean code. That's very difficult if the classes it's proxying for can't agree on a consistent behavior. The result might be lots of special cases in various levels of code, not to mention the possibility of a fatal error if any of the __call implementations try to behave like the language does. A change in the language could eliminate the ambiguity.

Hi Andrew, I understand your scenario and I agree but I think that this would be better done in userland by implementing an interface. Remember that all of the magic methods do not need to be declared, i.e. you will always be able to declare __call() without __iscallable(). This is quite a contrast to implementing an interface such as ArrayAccess, where offsetSet() and offsetExists() must always be defined in your class. The interface enforces a public contract and the behavior of the object is therefore always guaranteed, which is what you are seeking. In the case of __iscallable(), its behavior can never have such a guarantee because programmers may not declare it, so the inconsistency will always exist. With that being said, I don't think __iscallable() is a bad idea. My only reservation with adding it is that it's probably going to become even more confusing for users to remember which magic methods are available in which PHP versions. Best, Mike