I suppose it could be argued that if you want parameter overloading, then don't declare any parameters to the method and use func_get_args(). This WOULD give the userland code the appearance of parameter overloading. (I'm sure that this was mentioned). But I remember that there where "issues" with func_get_args (sorry - not really sure what they were).
But, with regards to the original topic "rethink OO inheritence strictness", this DOES seem that PHP is forcing userland code to obey 1 rule rather than allowing the user to extend as they see fit. On 02/08/06, Zeev Suraski <[EMAIL PROTECTED]> wrote:
I actually think this can be on a per method basis, so that methods where it's strictly required (such as certain magic method as Marcus said) will be able to set it, without affecting the entire class. It's at the method level that the developer knows whether overriding methods must adhere to the same signature. My recommendation: - Add a new flag to methods (at the implementation level) that will allow to flag them as 'strict' - In case such a strict method is improperly overridden - error out (E_ERROR) - In case a non-strict method is improperly overridden - emit E_STRICT - Consider adding userland ability to set entire classes or methods as strict Most people who use 'strict OO' will have E_STRICT enabled and have their code E_STRICT clean, so providing userland support for tagging classes/methods as strict is probably not really necessary. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php