Internals:
Time to summarize.
It is clear to me that internals is divided on this issue. I don't
think it's a large enough issue to drag on, even when I disagree with it
- both theoretically and in practice.
For most OO developer, putting ctors as an abstract or in an interface
would not happen anyway, so this does not affect them.
** The current change represents a minor break in BC, that should be
noted in the manual. **
Also, a decision needs to be made on what to do with grandchildren. As
I mentioned, the following produces no E_FATAL and no warnings:
abstract class A { abstract public function __construct($a, $b); }
class B extends A { public function __construct($a, $b) {} }
class C extends B { public function __construct(ArrayObject $d) {}
While this is correct behavior to me (ability for concrete to use its
own ctor), using the *current logic* strict signature checking enforced
from an abstract, then the above is also wrong.
** Can we decide what to do with that situation? **
On 11/18/11 5:05 AM, Pierre Joye wrote:
I strongly disagree, this encourages bad practices. We could however
reduce the error level to warning.
I think this is a sufficient compromise- I don't see anything E_FATAL
about a signature change in ctors (I actually see nothing wrong with it,
but it's clear the community is divided there).
** Can we make that change? **
Thanks,
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
