Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55509
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU6LvwM+qDCKQr+XOUu8Ab+QK2=hbkykD_d=jWiAwB8ozA@mail.gmail.com>
References: <CAKUjMCXiYc63NKsUuYWXT-A-aPabdPV6142LP9h4-c=2aUxW=w@mail.gmail.com>
	<4E74E5A0.2030006@sugarcrm.com>
	<alpine.DEB.2.02.1109181708480.3630@whisky>
	<4E76320F.6010904@sugarcrm.com>
	<CAF+90c8oZ4ghsFBa7jHtp_AKqD0N0cDhMycpjFTpCkLV9qRsqQ@mail.gmail.com>
	<4E764137.9080507@sugarcrm.com>
	<CAEZPtU6yBMP3X8_EpUXauDifAWEJwXS4fki5HtYNybWoCQ0kFw@mail.gmail.com>
	<4E7685DE.6010805@sugarcrm.com>
	<CAEZPtU6LvwM+qDCKQr+XOUu8Ab+QK2=hbkykD_d=jWiAwB8ozA@mail.gmail.com>
Date: Mon, 19 Sep 2011 02:37:53 +0200
Message-ID: <CAH-PCH6MAcVcpN7y55vJmS9Kb2vVDoei0OKL6U=-WXUYZGJEag@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] __constructor parameter limitations.
From: tyra3l@gmail.com (Ferenc Kovacs)

On Mon, Sep 19, 2011 at 2:24 AM, Pierre Joye <pierre.php@gmail.com> wrote:
> On Mon, Sep 19, 2011 at 1:59 AM, Stas Malyshev <smalyshev@sugarcrm.com> w=
rote:
>
>> foo() is compatible with foo($a, $b) - since anywhere you can call funct=
ion
>> declared as foo($a, $b) you can also successfully call one declared as
>> foo(), it'd just ignore extra parameters - =C2=A0but it is not allowed (=
I gave an
>> example). It was bad when it was a useless E_STRICT, it is much worse wh=
en
>> it's a fatal error.
>
> It is not compatible as the two new parameters are not optional.
> foo($a=3Dnull, $b=3D2) would be compatible. The only difference is that
> (if we don't fail with the signature checks) warnings will be raised
> for the missing arguments. But basically the problem is actually the
> incompatible signature. Take this code:
>
> class foo{
> =C2=A0function __construct(){}
> }
> class bar extends foo{
> =C2=A0function__construct($a, $b){}
> }
>
> if (is_a('bar', 'foo')) {
> =C2=A0$a =3D new bar(); // warnings and maybe unexpected results due to t=
he
> lack of arguments
> }
>
> to me (and to the OO concepts), they should fail at compile time to
> avoid any kind of confusions or bad consequences/usage. But I can
> understand that a fatal error could be seen as too extreme.
>
>
>>> Are you saying that extending a class and making the constructor
>>> incompatible with the extended class is a good thing to allow and to
>>> do? If yes then I'd to strongly disagree with this idea as it allows
>>
>> I never said anything about constructor being "incompatible" with extend=
ed
>> class and it being good thing. I am saying rejecting compatible but not
>> matching signatures - and I gave example of foo() vs foo($a, $b) - makes=
 no
>> sense. And not even with E_STRICT - it's a fatal error now!
>
> Given that your example is not compatible, it is then fine to reject them=
.
>
>>> And finally, the reason why abstract differs from the other areas is
>>> that they are newer. It was decided not to break BC for the other
>>> cases where we should have done the same. While Marcus wanted to do it
>>> everywhere, with the same good reasons.
>>
>> I guess "all abstracts do that" is better than "abstracts except for cto=
rs
>> do that" but only marginally as both behaviors make little sense to me.
>> Being restricted to abstracts limits the BC impact (as people could just
>> remove the abstract keyword and thus avoid trouble relatively easily) bu=
t in
>> both cases it doesn't look too good.
>
> Where is the BC impact with abstract? It was always like that. It
> happens to affect some newly written codes now but the behaviors is
> not new.
>
>> I'm not sure if we should keep the new BC-breaking error in 5.4 for
>> consistency sake (I'd felt much easier if we had discussed that before -=
 or
>> we did and I just forgot?), but I seriously think we need to rework it i=
n
>> 5.5 and make all compatible signatures work without complaining.
>
> Which BC break fix? afair there is one bug fix Gustavo made which
> creates bad side effects (about parent not being called or something
> like that). Etienne was planning to work on that to find a better
> solution. I don't have the bug # at hand but either Etienne or Gustavo
> could explain it better,
>

the __construct was handled differently, as the other methods, so this
was valid before 5.4:

<?php

abstract class BaseClass {
   abstract public function __construct(Type1 $foo, Type2 $bar);
}

class ExtendedClass extends BaseClass {
  public function __construct() {
  }
}

now the constructor also uses the same restrictions for abstract
classes as the other methods.
it's not a problem in itself, I'm just answering the question that
which bugfix is Stas referring to.


--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu