[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:
Comments welcome!
Zeev
[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:
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
Copying from old thread...please ignore the original.
-----Original Message-----
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Saturday, February 21, 2015 8:12 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFCZeev,
First off, thanks for putting forward a proposal. I look forward to a
patch
that can be experimented with.There are a few concerns that I have about the proposal however:
Proponents of Strict STH cite numerous advantages, primarily around code
safety/security. In their view, the conversion rules proposed by Dynamic
STH
can easily allow ‘garbage’ input to be silently converted into arguments
that
the callee will accept – but that may, in many cases, hide
difficult-to-find
bugs or otherwise result in unexpected behavior.I think that's partially mis-stating the concern.
I don't think it is, based
The sentence stresses garbage in too much to read as accurate. To
clarify, there is a) garbage in due to weak coercion and b) a function
being called with a string when the typehint says int. Both are
separate concerns around error detection. Stricter coercion can enable
only one of these two, for example. That's better than neither, of
course! The coercion rules were stricter than I expected based on
previous emails. Stressing one too much might suggest to a reader that
the second concern does not exist.
Other pedantic comment: "numerous" is probably too strong a word
there. The advantages may vary by person, but usually fit within basic
five-finger math. It would be more important to enumerate them rather
than selecting one as primary.
On the RFC rules themselves, a few comments:
- Happy to see leading/trailing spaces excluded.
- Rules don't make mention of leading zeroes, e.g. 0003
- "1E07" might be construed as overly generous assuming we are
excluding stringy integers like hex, oct and binary - I'm assuming the stringy ints are rejected?
- Is ".32" coerced to float or only "0.32"? Merely for clarification.
- Boolean coercion from other types... Not entirely sure myself.
Completely off the cuff: <=0: false, >0:true, floats and strings need
not apply. - In string to float, only capital E or also small e?
- I'll never stop call them "stringy" ints.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
On the RFC rules themselves, a few comments:
- Happy to see leading/trailing spaces excluded.
- Rules don't make mention of leading zeroes, e.g. 0003
- "1E07" might be construed as overly generous assuming we are
excluding stringy integers like hex, oct and binary- I'm assuming the stringy ints are rejected?
- Is ".32" coerced to float or only "0.32"? Merely for clarification.
- Boolean coercion from other types... Not entirely sure myself.
Completely off the cuff: <=0: false, >0:true, floats and strings need
not apply.- In string to float, only capital E or also small e?
- I'll never stop call them "stringy" ints.
In my mind, certainly a better proposition than those introducing dual
mode. Agree with the comments above, except that I am entirely sure that
boolean coercion from other types should not be allowed.
Cheers,
Ole Markus