Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21382
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Tue, 3 Jan 2006 19:37:26 -0500
To: Marcus Boerger <helly@php.net>
Cc: php internals <internals@lists.php.net>
Message-ID: <20060104003725.GH26280@desario.homelinux.net>
References: <20060103205728.GF26280@desario.homelinux.net> <1852411085.20060103220656@marcus-boerger.de> <20060103213332.GG26280@desario.homelinux.net> <1462157471.20060103225024@marcus-boerger.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1462157471.20060103225024@marcus-boerger.de>
User-Agent: Mutt/1.5.11
Subject: Re: [PHP-DEV] __call overload detection
From: andrew@plexpod.com (Andrew Yochum)

Hi Marcus,

On Tue, Jan 03, 2006 at 10:50:24PM +0100, Marcus Boerger wrote:
> Hello Andrew,
> 
>   you do not implement __call for a method but you deal with the method name
> in any sense you like, which also includes ignoring specific __call
> invocations. Reflection gives you the ability to check whetehr a function
> is being physically available. If you need more it is up to you to provide
> the infrastructure. Remember we will not in anyway allow __call to handle
> inheritance.
> 
> regards
> marcus

Gotcha.

So to be clear, here's what the language has and behaves now:
1. __call allows for method overloading
2. interfaces, method_exists, and Reflection API tells if a physical
method exists - including __call method itself
3. is_callable tells if a method is callable (always true if __call
is implemented)
4. Calls to a non-existent method on classes w/ no __call overloading
results in a fatal error
5. Calls to a non-existent method on classes w/ __call overloading
succeeds, but result is undefined.

And how to use it:
1. Determining if a physical method exists is easy through interfaces,
method_exists, reflection APIs
2. Implementations of __call may do what they like with the invocations
such as ignore silently, trigger an error, throw an exception or
implement some other kind of custom protocol
3. To determine if a class implementing __call will respond to a method
invocation you must call it, regardless of side-effects, and must know
the protocol used by the class you're calling

I understand if the original intention was to use __call this way, and
that the language is not planned to change.  I suggest such a change for
the benefit of the language and its users by providing consistency.

It seems this behavior of method overloading introduces an inconsistency
in the language that breaks the ease-of-use mantra of PHP.  Why should a
class who uses method overloading behave differently than a class that
does not?

5.1 added the __isset and __unset methods for allowing property
overloading to behave consistently with regular properties, allowing
both classes that do and do not implement property overloading to behave
the same.  It seems appropriate that the method overloading behave
similarly.  An everyday end-user of the language should not need to know
if he's invoking or looking to invoke an overloaded method or not.

Regards,
Andrew

-- 
Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879