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&amp;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

Reply via email to