Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80125
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.207 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <CAOjCV8wshLQJYqRPXS7wEodwhkMK-_W0qvxzNMe1F=SYe8svmA@mail.gmail.com>
Date: Sat, 3 Jan 2015 20:09:32 +0000
Cc: Pierre Joye <pierre.php@gmail.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <93B11897-3B8E-4D71-A8EB-A2D67B5446E9@ajf.me>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me> <CAEZPtU79=VX1Scm6vVn-9iuHD=qqRoPMrsR4Ymqd9=QQeQbRCg@mail.gmail.com> <360F9366-07C2-4C7A-AC3C-D482AFDD9838@ajf.me> <CAOjCV8wshLQJYqRPXS7wEodwhkMK-_W0qvxzNMe1F=SYe8svmA@mail.gmail.com>
To: "Sebastian B.-Hagensen" <sbj.ml.read@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: ajf@ajf.me (Andrea Faulds)

Hi Sebastian,

> On 3 Jan 2015, at 19:46, Sebastian B.-Hagensen <sbj.ml.read@gmail.com> =
wrote:
>>=20
>> Yeah, I don=E2=80=99t like this behaviour much. I want to avoid =
inconsistency with the behaviour of extension functions (i.e. =
zend_parse_parameters) where possible, though. Since this has come up so =
much, I should probably make an RFC to change this aspect of ZPP=E2=80=99s=
 behaviour.
>=20
> That RFC should probably be voted on before this RFC proceeds into =
voting.

That would be the idea.

> After skimming through the RFC I'm unsure what the following code =
would produce:
>=20
> function test(int $a, int $b) {}
>=20
> test("10.4", 10.6);
>=20
> If a warning/notice is raised, fine. If it will just result in $a =3D=3D=
=3D
> (int)10 && $b =3D=3D=3D(int)10 :

The first argument would be converted to 10 and a notice (=E2=80=9CNon =
well formed numeric string=E2=80=9D). The second would also be converted =
to 10, but silently.

I agree with your sentiments about data loss, but I am reluctant to =
deviate much from the behaviour of internal functions to avoid the =
inconsistency that plagued the previous RFC.

> If type annotations wouldn't go beyond the safety that php currently
> provides by converting in specific contexts and casting what is the
> benefit in adding them?

They=E2=80=99re still much safer than what we currently have. An =
unhinted parameter will accept anything. A scalar hinted parameter =
won=E2=80=99t accept non-scalars, and will only accept certain scalars.

Plus, they also avoid the need to use things like docblocks for many =
functions where merely adding types would make them self-explanatory.

Thanks.

--
Andrea Faulds
http://ajf.me/