Re: [RFC] Scalar Type Hints
| From: | Matthew Leverton | Date: | Fri, 02 Jan 2015 16:35:50 +0000 |
| Subject: | Re: [RFC] Scalar Type Hints | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-80101@lists.php.net to get a copy of this message | ||
On Wed, Dec 31, 2014 at 2:27 PM, Andrea Faulds <ajf@ajf.me> wrote:
>
> Please read the RFC (and specification patch, if you wish) and tell me your thoughts.
>
My thoughts as a long time (non-voting) PHP user:
I'd much prefer if they were strict types. I have a bias toward this
because I prefer to be as strict as possible. It's not hard to type
my_func((int) $_GET['foo']) if I want easy conversion. This explicit
cast serves as a reminder that I'm being sloppy. I can quickly scan
and see if there are parts of my code that are more prone to bugs.
But I'm not opposed to the RFC. I think it's *way* better than
nothing, and I understand the arguments in its favor. My one
complaint: I don't like that it emits a notice. I treat notices as
broken code, and if it's proper to say (int) "7 things", then it ought
to be proper to send that into a function. With notices being a
possibility, I'll need to manually add (int) in front of everything
... at which point, we might as well have strict types. (Off-topic and
different RFC, but I think having return types that auto-cast is
weird, which is another reason I'd prefer strict types all around.)
Finally, I'm not sure that implementing both (strict / type juggling)
with different syntax is a good idea. I think I'd prefer one or the
other. I don't really want to keep track as a user of many composer
libs (etc) which authors decided I need to use strict types. Because I
wouldn't want to have two different styles of code depending on the
library I'm using, I'd end up again going back to assuming everything
was a strict type.
--
Matthew Leverton