Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80075
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <54A5E309.4050109@gmail.com>
Date: Fri, 2 Jan 2015 00:21:18 +0000
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <47A3057F-4C2C-4059-864F-EC8912F3D17D@ajf.me>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me> <54A466CB.9020400@gmail.com> <F4EB5BF5-E9B3-42C5-9291-88CB42A29207@ajf.me> <54A5E309.4050109@gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: ajf@ajf.me (Andrea Faulds)

Hi Stas,

> On 2 Jan 2015, at 00:15, Stanislav Malyshev <smalyshev@gmail.com> =
wrote:
>=20
> Hi!
>=20
>> Yeah, it=E2=80=99s a problem. I think some breakage here is =
inevitable,
>> unfortunately. Some of the classes with these names are stand-ins for
>> scalar type hints, so that code can =E2=80=9Cjust=E2=80=9D migrate to =
using actual
>> hints. But this doesn=E2=80=99t apply to all of them.
>=20
> Breaking ZF2 and all software built on it is not "some breakage", it's =
a
> serious issue which would produce a big barrier for PHP 7 migration. =
And
> looks like there are more frameworks that do the same. This would be a
> barrier to PHP 7 adoption, and note that is even for people that
> couldn't care less for scalar typing. We'd find ourselves in python 3
> situation - where people would be glad to upgrade but they use library =
X
> and it doesn't work and they have no idea how to fix it and they keep
> all their development on the old version and the new one never catches
> on. It'd be a shame if we spend all this effort on PHP 7 and get no
> adoption since people can't run their existing code on it.

I wouldn=E2=80=99t say it=E2=80=99s impossible to work around. You could =
rename the class to something which doesn=E2=80=99t conflict, but add a =
conditional class_alias for PHP 5. Codebases needing to work on both PHP =
5 and PHP 7 can switch to the new name, codebases only needing to work =
on PHP 5 can stick with the old name.

Does that sound workable?

>=20
>> We could choose to simply not prohibit them as class names, but that
>> creates a weird inconsistency where you can make =E2=80=98class =
Integer=E2=80=99 yet
>> =E2=80=98function foo(Integer $a)=E2=80=99 hints against the integer =
type, not your
>> class. Type hints are very widely used, so I doubt this would help
>> anyone, and we=E2=80=99d still be breaking existing code type hinting =
against
>> such classes.
>=20
> I'd rather make the hints case sensitive. In fact, of two BC breakages
> making classes case sensitive may be the lesser one (I'm not a big fan
> of either but at least the modern frameworks would probably all work =
and
> if some code does not it's possible to auto-fix it).

If they were case-sensitive, this would be inconsistent with other type =
names like array and callable.

Thanks!
--
Andrea Faulds
http://ajf.me/