Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99131
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.25.164 cause and error)
Reply-To: internals@lists.php.net
References: <CADqTB_jB2ic4jx84HXVBPDr2qbP-DnXe782quKwc6o-ERpJJVw@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>,
 PHP internals <internals@lists.php.net>
Message-ID: <269187f4-5924-a7cc-9163-40134546451f@fleshgrinder.com>
Date: Tue, 23 May 2017 21:38:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CADqTB_jB2ic4jx84HXVBPDr2qbP-DnXe782quKwc6o-ERpJJVw@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="u8ttHK5WOAiVTLvXjajCxvPFK6pl65gPv"
Subject: Re: [PHP-DEV] Parameter type widening RFC
From: php@fleshgrinder.com (Fleshgrinder)

--u8ttHK5WOAiVTLvXjajCxvPFK6pl65gPv
Content-Type: multipart/mixed; boundary="L8kbgS90HALNlQjPvOURlaKJ4Jt14uTo0";
 protected-headers="v1"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: Rasmus Schultz <rasmus@mindplay.dk>,
 PHP internals <internals@lists.php.net>
Message-ID: <269187f4-5924-a7cc-9163-40134546451f@fleshgrinder.com>
Subject: Re: [PHP-DEV] Parameter type widening RFC
References: <CADqTB_jB2ic4jx84HXVBPDr2qbP-DnXe782quKwc6o-ERpJJVw@mail.gmail.com>
In-Reply-To: <CADqTB_jB2ic4jx84HXVBPDr2qbP-DnXe782quKwc6o-ERpJJVw@mail.gmail.com>

--L8kbgS90HALNlQjPvOURlaKJ4Jt14uTo0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 5/23/2017 9:25 PM, Rasmus Schultz wrote:
> This parameter type widening RFC, I didn't know about, but I have a rem=
ark.
>=20
> The feature, as implemented, will allow accidental omission of type-hin=
ts,
> will it not?
>=20
> Previously, the implements keyword guaranteed a correctly type-hinted
> implementation - it's now possible to (purposefully, obviously, in cert=
ain
> 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.
>=20
> The addition of an explicit "mixed" or "any" pseudo-type would have mad=
e
> this possible, without losing the guarantee that the implements keyword=

> used to provide - that is, it would have been possible to have this fea=
ture
> for the few cases where it's useful, without affecting safety in the
> majority of other cases where it's not.
>=20
> I feel like this feature takes a pretty dangerous shortcut by simply
> removing a constraint check that we used to have - in favor of supporti=
ng a
> few rare cases, we removed a guarantee that interfaces and the
> implements-keyword has always provided.
>=20
> Those rare cases could have been supported in a safe manner by introduc=
ing
> 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.
>=20
> The RFC page doesn't link to any discussion, and the Github thread was =
shut
> down after some negative remarks.
>=20
> 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?
>=20

Hey Rasmus!

- Discussion: https://marc.info/?t=3D147972136200001&r=3D1&w=3D2

I also had a look at the GitHub discussion, and I think that the things
that were written there have nothing to do with your concern. The people
commenting there simply did not understand LSP.

That being said, your remark is actually more than legit and I have to
agree that this is indeed just crying out for static analysis tools to
add more warnings to code.

I would very much love to see "any", but introducing yet another keyword
is imho not a good idea. We have already an extremely mixed up
terminology, hence, "mixed" would do and match the existing grammar of
PHP nicely.

There is time left for PHP 7.2 (20. July I think), maybe this is fixable
before that? I guess this will require an RFC too though.

--=20
Richard "Fleshgrinder" Fussenegger


--L8kbgS90HALNlQjPvOURlaKJ4Jt14uTo0--

--u8ttHK5WOAiVTLvXjajCxvPFK6pl65gPv
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZJI/NAAoJEOKkKcqFPVVrVTMQAK0d7x7n8oLNdZPv0cUlx9CG
5pYNF7gu7QsL0ZaI4gSJaCG5E4gy2UKmBndDe/R3sWfdVvJQO/2M0Bw1dcfrBfUP
8ihDlgOJ2rwwf8grMocATWGmhCAjlXc87/uJAJ6wYNbW/l3XwwXleX9nPWZU4ob+
CqlKmeu0gulDF32E4fAG1fAeoL2OnpJhg0HzbD61GHVr0rUwLRwFLrG5nxsoqQDm
sOAOBoD1Esu5NOzVS8IqB0NXsJaosZk6KpLbTBGKxljo+bSqE9QSlwqZFVZ/ZOFv
rS/S6hSAh0CkL3FZti9Tvo6L0DqdQIZ9Kb5fFPY6dKN1YvzRkLeh5eCeq5DmdT2M
yW+RnFbnxZM/Qiau19WGnYpfb4j4rxHS32netOE23jd7pByVH7c1C8vA8zyBAk3S
+CLu+EhR/Dz/jZksKAEAZ48MloiQ5jhl6wuhTczyHhV0S0dAcTuvzperihpkyhD/
UgXEBpxIhs0JfpfS58dztkkBzWPlpSD6JQxrz4P6kQ+yYCxxjHsHrz9QkCvbcl8E
1e4/uKEPEC2biiKu/m5fQYqDFLSBU0FaNqitGgmCk8+GZIoXDJNFekT0XPBtrjUz
b0wMb1WMQEUTMS7Qn0k3eYhhb8pIAMHtypwntTf/0x2FxeA3/iQ81bB6iFY7oYrM
K9W4N7N6KysTcfH4nZnT
=UVXI
-----END PGP SIGNATURE-----

--u8ttHK5WOAiVTLvXjajCxvPFK6pl65gPv--