Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56522
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4ECD3A9E.7090105@ralphschindler.com>
References: <4EC578C9.4000408@ralphschindler.com>
	<alpine.DEB.2.02.1111180954250.5937@whisky>
	<CAEZPtU4FHG_PTezL+LbweftuRu4248Rgmo2HJLtSBFV=nNo9Lg@mail.gmail.com>
	<4ECD3A9E.7090105@ralphschindler.com>
Date: Wed, 23 Nov 2011 13:37:02 -0500
Message-ID: <CAAyV7nGiTSohi456=jPEqm8O4jCBLkGCRmTkJtM8iPH1Oc+D=Q@mail.gmail.com>
To: Ralph Schindler <ralph@ralphschindler.com>
Cc: Pierre Joye <pierre.php@gmail.com>, Derick Rethans <derick@php.net>, 
	internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Changes to constructor signature checks
From: ircmaxell@gmail.com (Anthony Ferrara)

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. =A0I don't thi=
nk
> 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 wo=
uld
> not happen anyway, so this does not affect them.
>
> ** The current change represents a minor break in BC, that should be note=
d
> in the manual. **
>
> Also, a decision needs to be made on what to do with grandchildren. =A0As=
 I
> mentioned, the following produces no E_FATAL and no warnings:
>
> =A0abstract class A { =A0abstract public function __construct($a, $b); }
> =A0class B extends A { public function __construct($a, $b) {} }
> =A0class 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 abo=
ut
> 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
>
>