Re: [RFC] Scalar Type Hints
| From: | Andrea Faulds | Date: | Wed, 31 Dec 2014 21:11:08 +0000 |
| Subject: | Re: [RFC] Scalar Type Hints | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-80030@lists.php.net to get a copy of this message | ||
Hey Adam,
> On 31 Dec 2014, at 20:51, Adam Harvey <aharvey@php.net> wrote:
>
> 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:
>
> 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) — 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’t really want to support multiple names for each type. I’m
alright with allowing short and long forms (int/integer, bool/boolean), because it’s fairly
obvious to users that they mean the same thing, and we don’t use either form consistently.
However, I don’t like completely different type names like ‘long’, ‘double’ and
‘real’. Luckily, in master, we no longer use ‘long’ or ‘double’ in error messages, and I
don’t think we’ve ever used ‘real’ anywhere outside of the cast operator. So, I don’t
think it’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.)
>
> 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 — 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’t 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/