Re: Changes to constructor signature checks

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 <ralph@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 > >