Hello Andrew, you got everything correct and i see your point, so you may want to open a feature request under bugs.php.net.
marcus Wednesday, January 4, 2006, 1:37:26 AM, you wrote: > 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 > [EMAIL PROTECTED] > 718-360-0879 Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
