Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80030
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: <CADajX4DrvaXwfGWzmWv1XZMi+=ytHEVWx0-rtHnQHwkJJSDfhg@mail.gmail.com>
Date: Wed, 31 Dec 2014 21:11:08 +0000
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <15210D8C-2B22-4818-B5B4-392A06AAF346@ajf.me>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me> <CADajX4DrvaXwfGWzmWv1XZMi+=ytHEVWx0-rtHnQHwkJJSDfhg@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: ajf@ajf.me (Andrea Faulds)

Hey Adam,

> On 31 Dec 2014, at 20:51, Adam Harvey <aharvey@php.net> wrote:
>=20
> At a first read through, this looks great, and much more in line with
> what I'd like scalar type hints to look like. Nice job!

Glad to hear that!

> In terms of the open issues, here's what I think:
>=20
> 1. Aliases: I think we should support the same set of names as we
> currently support for type casts[0] (excluding non-scalar types,
> obviously) =E2=80=94 this actually expands the list a little more, =
since there
> are three (!) variants for floating point values, but I think it's
> important to be consistent in all the places in the language where we
> use "type" names.

I had thought about this. I don=E2=80=99t really want to support =
multiple names for each type. I=E2=80=99m alright with allowing short =
and long forms (int/integer, bool/boolean), because it=E2=80=99s fairly =
obvious to users that they mean the same thing, and we don=E2=80=99t use =
either form consistently. However, I don=E2=80=99t like completely =
different type names like =E2=80=98long=E2=80=99, =E2=80=98double=E2=80=99=
 and =E2=80=98real=E2=80=99. Luckily, in master, we no longer use =
=E2=80=98long=E2=80=99 or =E2=80=98double=E2=80=99 in error messages, =
and I don=E2=80=99t think we=E2=80=99ve ever used =E2=80=98real=E2=80=99 =
anywhere outside of the cast operator. So, I don=E2=80=99t think it=E2=80=99=
d cause problems to not allow these as type hints.

> 2. Prohibiting use in class names: I think this makes sense, otherwise
> we'll be violating the principle of least surprise when somebody does
> call a class Int. (Yes, namespacing might help here, but I think I'd
> rather restrict it altogether rather than trying to come up with rules
> around when you can call a class "int" and how you'd refer to it.)
>=20
> To bang another drum (and this shouldn't be responded to in this
> thread, since we have another one going for this RFC): this sort of
> change is why 5.7 is vital for migration =E2=80=94 emitting =
deprecation
> warnings for users calling classes by names that we'll be prohibiting
> in PHP 7 is important, and will help our users migrate their code
> bases.

I hadn=E2=80=99t thought of that, but yes, having a deprecation notice =
for this in 5.7 would be a good idea.

Thanks for your comments.

--
Andrea Faulds
http://ajf.me/