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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
