Re: [RFC] Coercive Scalar Type Hints
| From: | Pierre Joye | Date: | Sat, 21 Feb 2015 17:54:55 +0000 |
| Subject: | Re: [RFC] Coercive Scalar Type Hints | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-83410@lists.php.net to get a copy of this message | ||
On Sat, Feb 21, 2015 at 9:51 AM, Zeev Suraski <zeev@zend.com> wrote:
> [Resending with the correct Subject line :)]
>
> ---
>
> All,
>
>
>
> I’ve been working with François and several other people from internals@
> and the PHP community to create a single-mode Scalar Type Hints proposal.
>
>
>
> I think it’s 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.
>
>
>
> The RFC is available here:
>
>
>
> wiki.php.net/rfc/coercive_sth
>
>
>
> Comments welcome!
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):
“42.0” should not be accepted. This is a float not an integer. 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 >=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
@pierrejoye | http://www.libgd.org