Hello all,
This crept up as the result of a bug report (not mine --
http://bugs.php.net/34494), and a small discussion on IRC:
Why does an E_STRICT get raised when extending a class, and altering the
method's proto defaults? I understand why it would be thrown when
adding/changing parameters, but why when simply changing $foo to $foo=1 ?
Honest question -- I'm not trying to change the behavior, here. It
doesn't seem "correct" to me, but I look forward to an explanation that
I've simply overlooked.
S
Hello Sean,
Wednesday, September 21, 2005, 4:54:31 PM, you wrote:
Hello all,
This crept up as the result of a bug report (not mine --
http://bugs.php.net/34494), and a small discussion on IRC:
Why does an
E_STRICTget raised when extending a class, and altering the
method's proto defaults? I understand why it would be thrown when
adding/changing parameters, but why when simply changing $foo to $foo=1 ?
Honest question -- I'm not trying to change the behavior, here. It
doesn't seem "correct" to me, but I look forward to an explanation that
I've simply overlooked.
S
marcus@zaphod /usr/src/PHP_5_1 $ php -r 'class T{function f($x){}} class U extends T{function f($x=2){}}'
make: `sapi/cli/php' is up to date.
Strict Standards: Declaration of U::f() should be compatible with that of T::f() in Command line code on line 1
marcus@zaphod /usr/src/PHP_5_1 $ php -r 'class T{function f($x=1){}} class U extends T{function f($x=2){}}'
make: `sapi/cli/php' is up to date.
The above shows php is correct here.
Best regards,
Marcus
Marcus Boerger wrote:
marcus@zaphod /usr/src/PHP_5_1 $ php -r 'class T{function f($x){}} class U extends T{function f($x=2){}}'
make: `sapi/cli/php' is up to date.Strict Standards: Declaration of U::f() should be compatible with that of T::f() in Command line code on line 1
marcus@zaphod /usr/src/PHP_5_1 $ php -r 'class T{function f($x=1){}} class U extends T{function f($x=2){}}'
make: `sapi/cli/php' is up to date.The above shows php is correct here.
In my opinion Sean didn't ask whether PHP behaves that way but why.
And I don't really see the point either as U::f works with all code
previously using T::f. Even more so for function V::f($x,$y=false) to
provide extended functionality to T::f($x) for code which knows about
it. And why would changing the default value be ok in your book? But
then again I'm not an OO purist and I don't (have to) use E_STRICT.
- Chris
Christian Schneider wrote:
Even more so for function V::f($x,$y=false) to
provide extended functionality to T::f($x) for code which knows about it
Ok, forget that part, I made a typo when testing this ;-)
Apologies,
- Chris
Hello Christian,
Wednesday, September 21, 2005, 10:37:01 PM, you wrote:
Marcus Boerger wrote:
marcus@zaphod /usr/src/PHP_5_1 $ php -r 'class T{function f($x){}} class U extends T{function f($x=2){}}'
make: `sapi/cli/php' is up to date.Strict Standards: Declaration of U::f() should be compatible with that of T::f() in Command line code on line 1
marcus@zaphod /usr/src/PHP_5_1 $ php -r 'class T{function f($x=1){}} class U extends T{function f($x=2){}}'
make: `sapi/cli/php' is up to date.The above shows php is correct here.
In my opinion Sean didn't ask whether PHP behaves that way but why.
The above example show that adding a default result value in a derived class
results in an incompatible signature while changing it works as expected.
Best regards,
Marcus