Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99134
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.160 cause and error)
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 22:46:50 +0200
Message-ID: <CANUQDCjpjz8Wret1D6q9wb8rfBH4Xqc4uDqLTtuptkUdesUK4g@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a114639d0488a0d0550371633"
Subject: Re: [PHP-DEV] Parameter type widening RFC
From: me@kelunik.com (Niklas Keller)

--001a114639d0488a0d0550371633
Content-Type: text/plain; charset="UTF-8"

Hi Rasmus,


> 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?
>

Yes, correct.


> 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 interface will just work correctly, what's the actual problem you're
seeing?


> 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.
>

Unfortunately, that doesn't work for the second (maybe even primary) use
case of the RFC: Adding types to a class isn't a BC break anymore with the
RFC, as child classes will just widen the type and need explicit checks as
before. Without the RFC or with a version with "mixed" or "any", method
signatures will be incompatible again and thus be a BC break when adding
types to the base class.

"mixed" has been mentioned in the original discussion, but there was not a
lot of interest and mostly explicit disinterest.


> 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?


 - Original discussion: https://externals.io/thread/505
 - Vote announcement: https://externals.io/thread/613
 - Vote resumption after internals having issues:
https://externals.io/thread/619

Regards, Niklas

--001a114639d0488a0d0550371633--