Re: __call overload detection

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