Everything

php

E_STRICT on inheritance + method parameter defaults?

php.internals

Sean Coates

20 years ago

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

Marcus Börger

20 years ago

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_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

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

Christian Schneider

20 years ago

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

20 years ago

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

Marcus Börger

20 years ago

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