Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105169
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
In-Reply-To: <CAF+90c_Xcz6rTq_CdAFdGBhW2eLDZOVEkLRgKgJZTwRQSsTTBA@mail.gmail.com>
Date: Tue, 9 Apr 2019 12:58:26 +0200
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <3BCEA463-BD9B-468B-AF26-E0AD75C5F559@gmail.com>
References: <CAF+90c_Xcz6rTq_CdAFdGBhW2eLDZOVEkLRgKgJZTwRQSsTTBA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Always generate fatal error for incompatible
 method signatures
From: gadelat@gmail.com (Gabriel O)

I see you are trying to solve inconsistency, but i would do it opposite =
way. LSP errors should be warnings, they are not show stopper errors. =
It=E2=80=99s very much possible code violating LSP keeps working =
correctly. And in modern PHP development, everybody considers warnings =
as show stoppers anyway, so impact here is only in production. When some =
LSP breakage sneaks unnoticed into production and my INI settings just =
silence these and log them, I would prefer it to not crash there, =
because problem with these show only when expecting parent but receiving =
child, not when child breaks LSP but its nowhere used in place of =
parent.

And this RFC conveniently shows only big LSP violation examples like =
array -> int, but not widely used narrowing like mixed/object -> =
specific instance.

> On 9. Apr 2019, at 10:25, Nikita Popov <nikita.ppv@gmail.com> wrote:
>=20
> Hi internals,
>=20
> A small cleanup RFC for PHP 8: https://wiki.php.net/rfc/lsp_errors
>=20
> This makes all incompatible method signature (LSP) errors fatal, =
rather
> than only warning in some cases. Especially after
> https://wiki.php.net/rfc/parameter-no-type-variance I don't think =
there's
> any reason to keep this backdoor in place.
>=20
> Regards,
> Nikita