Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99132
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADqTB_jB2ic4jx84HXVBPDr2qbP-DnXe782quKwc6o-ERpJJVw@mail.gmail.com>
References: <CADqTB_jB2ic4jx84HXVBPDr2qbP-DnXe782quKwc6o-ERpJJVw@mail.gmail.com>
Date: Tue, 23 May 2017 21:51:03 +0200
Message-ID: <CAF+90c-A6hUi1da+pd7x=OaBgiUkZH1-+8d=LpMM5MzMVwDFng@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="f403045d9712cfd5c30550364edc"
Subject: Re: [PHP-DEV] Parameter type widening RFC
From: nikita.ppv@gmail.com (Nikita Popov)

--f403045d9712cfd5c30550364edc
Content-Type: text/plain; charset="UTF-8"

On Tue, May 23, 2017 at 9:25 PM, Rasmus Schultz <rasmus@mindplay.dk> wrote:

> This parameter type widening RFC, I didn't know about, but I have a remark.
>
> The feature, as implemented, will allow accidental omission of type-hints,
> will it not?
>
> Previously, the implements keyword guaranteed a correctly type-hinted
> implementation - it's now possible to (purposefully, obviously, in certain
> rare cases) omit type-hints by accident, making the implements keyword much
> less (or not any) of a guarantee that the interface is implemented
> correctly.
>
> The addition of an explicit "mixed" or "any" pseudo-type would have made
> this possible, without losing the guarantee that the implements keyword
> used to provide - that is, it would have been possible to have this feature
> for the few cases where it's useful, without affecting safety in the
> majority of other cases where it's not.
>
> I feel like this feature takes a pretty dangerous shortcut by simply
> removing a constraint check that we used to have - in favor of supporting a
> few rare cases, we removed a guarantee that interfaces and the
> implements-keyword has always provided.
>
> Those rare cases could have been supported in a safe manner by introducing
> a "mixed" or "any" type, which would have made the use of this feature
> explicit - which would have removed the risk of accidental omission of
> type-hints in the majority of cases.
>

One of the primary motivations behind this RFC is to allow the addition of
typehints (for example in library code) without introducing a backwards
compatibility break for any code implementing or extending your
interface/class. Requiring an explicit "mixed" or "any" type would not
allow this. I think this is 95% of the reason for this RFC, so without it,
the change itself is probably not worthwhile.


> The RFC page doesn't link to any discussion, and the Github thread was shut
> down after some negative remarks.



> I didn't see a discussion or a vote here on internals - did I miss
> something? Where or how did this get discussed and passed? Are these
> discussions happening somewhere else besides internals now?
>

The RFC was discussed in http://markmail.org/message/2oydyyl45v4korau. You
participated in that discussion.

The vote started in http://markmail.org/message/jgn4hwcgeezzk22w.

Both of those were found by searching for the literal RFC name.

Nikita

--f403045d9712cfd5c30550364edc--