Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21390
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <43BB2D6B.7070108@zend.com>
Date: Tue, 03 Jan 2006 18:05:31 -0800
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
MIME-Version: 1.0
To: Andrew Yochum <andrew@plexpod.com>
CC: internals@lists.php.net
References: <20060103205728.GF26280@desario.homelinux.net> <1852411085.20060103220656@marcus-boerger.de> <20060103213332.GG26280@desario.homelinux.net> <43BB0C61.1070806@zend.com> <20060104013756.GI26280@desario.homelinux.net>
In-Reply-To: <20060104013756.GI26280@desario.homelinux.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] __call overload detection
From: mike.n@zend.com (Mike Naberezny)

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