Ralph:
>From where I'm sitting, I can see a few sane alternatives (there may
be more, but here are the options I can see):
Option 1. Remove signature checking from constructors all together.
(I don't care for this, but whatever). Additionally, since it's not
enforced, perhaps an E_DEPRECATED or E_STRICT error should be raised
on definition, as it is superfluous...
Option 2. Fix grandchild signature checking to be inline for how
signatures work with other methods.
Personally, I think option 2 is the better one. I see it being odd
and inconsistent that all methods work one way, and constructors work
differently. But that's just my feeling (and I know others disagree
there).
And please don't reduce the error level of a signature change (as it
would introduce even more inconsistency)...
Just my $0.02...
Anthony
On Wed, Nov 23, 2011 at 1:25 PM, Ralph Schindler
<ra...@ralphschindler.com> wrote:
> 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
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
