Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81835
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <CAF+90c9DgfkumH5ADjjykGd4t6Ude1TA70r=C7Vw40xQg3RHrw@mail.gmail.com>
Date: Wed, 4 Feb 2015 18:54:20 +0000
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <5464CFC6-0E2B-4665-8BF3-D0F0118CF6F6@ajf.me>
References: <CAF+90c9DgfkumH5ADjjykGd4t6Ude1TA70r=C7Vw40xQg3RHrw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] Allow dropping typehints during inheritance
From: ajf@ajf.me (Andrea Faulds)

Hi Nikita,

> On 4 Feb 2015, at 18:49, Nikita Popov <nikita.ppv@gmail.com> wrote:
>=20
> Currently we do not allow [1] removing a typehint during inheritance. =
For
> example the following code is not valid:
>=20
>    interface A {
>        public function method(Typehint $param);
>    }
>    class B implements A {
>        public function method($param);
>    }
>    // Fatal error: Declaration of B::method() must be compatible with
> A::method(Typehint $param)
>=20
> The above code does *not* constitute an LSP violation, because =
B::method()
> accepts more inputs than A::method(). However we still forbid it.
>=20
> This is an issue, because it makes it impossible to add typehints to
> parameters at a later point in time. I've seen this issue come up both =
in
> userland code, as well as in a recent DateTime change, see
> =
https://github.com/php/php-src/commit/8e19705a93d785cd1ff8ba3a69699b00169f=
ea47
> .
>=20
> Instead of reverting the DateTime BC break, I'm wondering if it =
wouldn't be
> better to fix the root cause by making the inheritance check less =
strict
> and allow removing typehints?

Sounds sensible to me.

Of course, the reverse is true for return types, which should be either =
covariant or invariant. :)
--
Andrea Faulds
http://ajf.me/