Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107903
Message-ID: <4C8A8CB1-1259-439A-B213-D10D098010A6@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_B34488C8-16E8-462A-9985-91C5DBDABEDD"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 8 Dec 2019 00:03:00 -0500
In-Reply-To: <a68ab6cf-6a26-43c6-9b12-c41366cce01f@www.fastmail.com>
Cc: php internals <internals@lists.php.net>
To: Larry Garfield <larry@garfieldtech.com>
References: <a68ab6cf-6a26-43c6-9b12-c41366cce01f@www.fastmail.com>
Subject: Re: [PHP-DEV] Inconsistent class behavior and undocumented(?) BC
 change
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_B34488C8-16E8-462A-9985-91C5DBDABEDD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Larry,

> I am not clear on why __construct() is special in this case;

I believe that is the Liskok substitution principle at work, and that =
fact the principle does not apply to constructors.

For reference:

- https://softwareengineering.stackexchange.com/a/302477/9114
- =
https://www.sitepoint.com/constructors-and-the-myth-of-breaking-the-lsp/

-Mike

> On Dec 7, 2019, at 7:27 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> I am not sure if this is a bug, a feature behaving in a desired but =
confusing way, or a feature behaving in a confusing and thus =
undesireable way.  I am therefore reporting it here in order to defer to =
those who know the answer to such questions better.
>=20
> Consider the following:
>=20
> class Ancestor {
>    public function __construct(int $a, string $b) { }
> }
>=20
> class Child extends Ancestor {
>    public function __construct(...$args) {
>        parent::__construct(...$args);
>    }
> }
>=20
> This works with no compile errors.  For any other method however:
>=20
> class Ancestor {
>    public function doStuff(int $a, string $b) { }
> }
>=20
> class Child extends Ancestor {
>    public function doStuff(...$args) {
>        parent::doStuff(...$args);
>    }
> }
>=20
> I get:
>=20
> Warning: Declaration of Child::doStuff(...$args) should be compatible =
with Ancestor::doStuff(int $a, string $b)
>=20
> I am not clear on why __construct() is special in this case; I know =
__construct() is special where interfaces are concerned, but I didn't =
realize it was special with regards to basic inheritance.  It seems to =
happen regardless of the type information presented (or not).
>=20
> Is this intentional?  Is there a logical way it could be made to work? =
 Are constructors actually wrong here?  (I hope not, because it's a neat =
trick.)
>=20
> Additionally, according to 3v4l.org at least, the error message has =
changed.  On 7.1-7.3, the exact error message is:
>=20
> Warning: Declaration of Child::doStuff(int ...$args) should be =
compatible with Ancestor::doStuff($a, $b) in /in/6NthP on line 15
>=20
> On 7.4, it reports on a different line:
>=20
> Warning: Declaration of Child::doStuff(int ...$args) should be =
compatible with Ancestor::doStuff($a, $b) in /in/6NthP on line 11
>=20
> Specifically, prior to 7.4, it reports on the LAST line of the class =
(the closing brace).  As of 7.4 it reports on the line of the method =
that is inconsistent.
>=20
> I don't think this is a bad change, per se.  It's actually a good =
change for debugging, IMO.  But I don't see it listed in the migration =
guide.  Should it be, in case some failure-mode tests or other automated =
error systems care?
>=20
> https://www.php.net/manual/en/migration74.incompatible.php
>=20
> --=20
>  Larry Garfield
>  larry@garfieldtech.com
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20


--Apple-Mail=_B34488C8-16E8-462A-9985-91C5DBDABEDD--