Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97227
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CANUQDCg+g5toVyi5VKCSkgvot0tM2Vr-UmZ=uYLYOqLPd+9+vg@mail.gmail.com>
References: <CANUQDCg+g5toVyi5VKCSkgvot0tM2Vr-UmZ=uYLYOqLPd+9+vg@mail.gmail.com>
Date: Tue, 29 Nov 2016 18:40:11 +0100
Message-ID: <CAF+90c8O+YOwpXZmkHKS_bTa2TWR_ee=AdBZxc5kyeW0DzestA@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e014941448b02cb05427414a0
Subject: Re: [PHP-DEV] [RFC] Parameter No Type Variance
From: nikita.ppv@gmail.com (Nikita Popov)

--089e014941448b02cb05427414a0
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 21, 2016 at 10:39 AM, Niklas Keller <me@kelunik.com> wrote:

> Morning Internals,
>
> I'd like to announce a RFC to allow omitting the type declarations for
> parameters in subclasses:
> https://wiki.php.net/rfc/parameter-no-type-variance
>
> PHP doesn't currently allow variance for parameters as checking these for
> compatibility isn't possible on compile time.
> This limitation is caused by autoloading and doesn't allow widening the
> accepted parameters.
>
> This RFC proposes to allow ommiting the type entirely in a subclass, as
> dropping all parameter constraints is
> always valid according to the LSP principle.
>
> We already allow return types being added in subclasses.
>
> Your feedback is welcome. :-)
>
> Regards, Niklas
>

The RFC is a bit lacking in motivation ...

The main practical use-case I see for this is post-hoc addition of
type-hints on an interface. To cite a particular example we ran into for
PHP 7.0: Derick added a DateTimeZone type hint for the third arg of the
DateTime::createFromFormat() method [1]. The method is already documented
to accept only this class in the manual, but the typehint is not actually
present in the implementation.

However, this change had to be reverted, because all classes extending
DateTime currently don't have this typehint (and adding it would be illegal
under LSP), so they started throwing a method signature mismatch warning.

Allowing extending classes to drop typehints in accordance with
variance-rules allow people to add additional parameter typehints on parent
classes without breaking BC. (Adding an additional return typehint would
break BC, but it is still a cross-version compatible change, as consumers
have the possibility of writing code that is valid under both versions --
something that is currently impossible if you want to add parameter
typehints.)

Thanks,
Nikita

[1]:
https://github.com/php/php-src/commit/8e19705a93d785cd1ff8ba3a69699b00169fea47

--089e014941448b02cb05427414a0--