Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83407
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>
Date: Sat, 21 Feb 2015 09:46:10 -0800
Message-ID: <CAEZPtU5XvxyxtMPaoSu9jUvrock_sF0O5N30-SSGcAbUn=Dxtw@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Sat, Feb 21, 2015 at 9:22 AM, Zeev Suraski <zeev@zend.com> wrote:
> All,
>
>
>
> I=E2=80=99ve been working with Fran=C3=A7ois and several other people fro=
m internals@
> and the PHP community to create a single-mode Scalar Type Hints proposal.
>
>
>
> I think it=E2=80=99s the RFC is a bit premature and could benefit from a =
bit more
> time, but given the time pressure, as well as the fact that a not fully
> compatible subset of that RFC was published and has people already
> discussing it, it made the most sense to publish it sooner rather than
> later.

This does not provide what I consider as the best compromise. An
optional per file/package strict mode and a fully compatible with
existing mode.

However here are some comments:

Integer STH (int):
=E2=80=9C42.0=E2=80=9D should not be accepted. This is a float not an integ=
er. It
introduces edge cases I would rather avoid (precision setting f.e.,
imagine "42.000001" or "42.0001"?)

Boolean STH (bool):
this is by far too weak. How strings could be consider as valid, how?
"true" > Boolean true? I suppose then "false" will be boolean false?
What's is the boolean value of float 0.5?
At the very least only integer should be accepted, 0 > false, anything >=3D=
1 true

Changes to Internal Functions:
I am generally speaking against changing them by default, this is a
too big BC break.

This RFC is also not complete. A test should be provided to valid the
changes against existing applications. I suspect the impact may not be
as small as we think. I can be wrong here but tests will tell me how
wrong I could be :)

And finally, this RFC only proposes one solution, so competitive RFCs
are still required to actually represent alternatives.

Cheers,
Pierre