Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80047
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: <54A52AE6.70704@fischer.name>
Date: Thu, 1 Jan 2015 15:19:04 +0000
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <CDBE6BAD-1345-432B-AE0A-3160697BBF05@ajf.me>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me> <54A5051F.1090400@php.net> <54A52AE6.70704@fischer.name>
To: Markus Fischer <markus@fischer.name>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: ajf@ajf.me (Andrea Faulds)

Hi Markus,

> On 1 Jan 2015, at 11:09, Markus Fischer <markus@fischer.name> wrote:
>=20
> 1. the naming of the RFC thus the intent is confusing
>=20
> What it really does is it tries its best to convert, e.g. the RFC =
reads
> as it tries to work like this:
>=20
> function foo(int $bar) {
>  $bar =3D (int)$bar;
> }
>=20
> =46rom your description I understand that, technically, it doesn't do =
that
> exactly; I was merely trying to make a point how it "looks it works";
> see my next point.

I think it=E2=80=99d be weird to have different syntaxes for scalars and =
non-scalars. We already use the syntax the RFC proposes in the PHP =
manual, and I don=E2=80=99t think anyone=E2=80=99s confused by it.=20

I realise that the behaviour of scalar type hints is slightly different =
from the hints for complex types, but I think this would just look ugly:

    function foo((int) $bar, Foo $baz, (float) $qux);

> 2. Casting and Validation Rules
>=20
> "While this RFC merely follows PHP's existing rules for scalar
> parameters, used by extension functions, these rules may not be =
familiar
> to all readers of this RFC."
>=20
> Very good job in pointing this out! Which brings me to this question:
> are these different rules than the general casting rules (as I =
exampled
> above) ? If yes, wouldn't this increase the burden on PHP developers
> even more to learn new rules (and, those rules are already to many to
> sanely remember).

Yes and no. With the exception of hexadecimal numbers in strings, =
explicit casts and internal functions follow the same rules for =
conversion. However, the validation rules don=E2=80=99t match. Explicit =
casts never fail, while internal functions will reject arguments that =
are non-scalar or don=E2=80=99t fit certain rules.

> 3. "Non-numeric strings not accepted. Numeric strings with trailing
> characters are accepted, but produce a notice. "
>=20
> That behavior, IMHO, is very bad for this kind of feature.
>=20
> What's the point of continuing the code when developer asked for "int"
> and code logic continues with "something not quite an int"?
>=20
> Doesn't that defeat the whole purpose of the use of this RFC?
>=20
> I know that this can be fixed using an error handler, throwing an
> exception to abort code execution but that should really be an error
> anyway, IMHO, on par with a gross mismatch of types.

I can=E2=80=99t say I love that behaviour either. It is, however, our =
existing behaviour. I=E2=80=99d rather we be consistent with internal =
functions.

Thanks.
--
Andrea Faulds
http://ajf.me/