On Mon, Feb 16, 2015 at 10:04 PM, Zeev Suraski <z...@zend.com> wrote:
> That syntax poll aside, I had what I hope is some sort an enlightenment, and
> I think I know what will get me to cast my vote in favor of 'strict', as a
> true supporter. There's one very special conversion that's too common in
> PHP to dismiss (IMHO), and is also completely harmless in 99.999% of the
> cases, if not strictly 100%:
>
> string->int or string->float conversions, when the string looks *exactly*
> like a number. Given almost all of our inputs (from databases, forms,
> files, etc.) come in string form, that's by far the conversion that's going
> to give us the most trouble - and is most probably the use case that by far
> is going to result the largest amount of explicit casts to work around that
> problem.
>
> What if strict mode didn't just blindly check zval.type, but actually
> allowed for this one type of conversion to go through without a problem?
>
> No bool to int. No Apple to int. No "123 testing" to float. Just "32" to
> 32 and "37.7" to 37.7.
>
> Can the strict supporting camp consider that option? Judging by the
> examples brought up by proponents of v0.3, this type of conversion isn't
> their issue. It's the 'obviously wrong' conversions that bug them.
>
> As a secondary concern I'd put int to float conversions where no
> (meaningful) data is being lost, e.g. 37 -> 37.0, even though a tiny bit of
> accuracy is lost. Rejecting this particular conversion places us at being
> stricter than mostly all other languages. That said, it's a much less
> common conversion so I don't feel nearly as strongly about it as the string
> one.
>
> Last, regarding internal functions, I do agree with Rasmus and Drew. Again,
> judging by the examples brought up as a part of the discussion, it seems as
> if we gave ZPP developers a standard easy way of being a lot more picky
> about the types of values of particular arguments, and allowing them to do
> this selectively for those places that are very sensitive (e.g.
> curl_setopt()) would be a more suitable solution than just turning strict
> validation for all internal functions, which were built with very very
> different assumptions in mind. The biggest difference between internal
> functions and userland functions in the context of this RFC is that with
> userland functions, we're starting with a clean slate. There are no type
> hint definitions anywhere, developers can selectively add them as they see
> fit. With internal functions, we have type requirements EVERYWHERE already,
> but with semantics that didn't take strict typing into account at all and
> evolved for almost 20 years. Strict typing the way it is now would
> radically change these semantics overnight, and will make the adoption of
> strict a much bigger headache than it can be, as I believe Rasmus
> demonstrated.
>
> I think addressing these issues could get us a LOT closer to consensus and
> make a lot of those who voted 'no' on v0.3 vote yes on v0.4.
>
So, if you'll permit me to summarize your message. The following
would be palatable to you?
* Lossless coercion. This would sit somewhere between strict types
and weak types as lossy conversions (object->__toString() for objects
passed where string expected, any->bool) would be disallowed, but
lossless conversions (numeric strings to number types, int to float,
whole floats to ints, numbers to strings -- But no implicit
conversions to bools, no non-numeric strings to numerics, etc...)
* Exclude internal functions from the strict switch. (Perhaps have a
separate switch for internal functions at a later date)
With option to introduce features such as the following at a later date:
* Union types (e.g. function foo((int | float) $value): (bool | string) { ... })
* Typedefs (e.g. TypeDef (int|float) numeric; -- Some defined as
standard (like numeric), others user-definable)
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
