Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80102
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <CAN=kQJfG9Q5MVztMEPCiCWabYW6_F5fHATLxyWQic_aVizBwvA@mail.gmail.com>
Date: Fri, 2 Jan 2015 16:39:21 +0000
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <DC20905F-0099-46C3-8A8B-53BA0E657E15@ajf.me>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me> <CAN=kQJfG9Q5MVztMEPCiCWabYW6_F5fHATLxyWQic_aVizBwvA@mail.gmail.com>
To: Matthew Leverton <leverton@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: ajf@ajf.me (Andrea Faulds)

Hey Matthew,

> On 2 Jan 2015, at 16:35, Matthew Leverton <leverton@gmail.com> wrote:
>=20
> 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.

One problem with explicit casts like (int) is they never throw errors, =
unlike implicit casts. takes_int([]) is an error, (int)[] isn=E2=80=99t. =
There was a safe casting functions RFC, but that was rejected. Still, =
yes, you have a point in that the sloppiness is more obvious.

> 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.)

I=E2=80=99m not a fan of this behaviour either, but it is the behaviour =
we already have. Another RFC could fix it. I should probably write one.

> 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.

This is how I feel.

Thanks.
--
Andrea Faulds
http://ajf.me/