In a word, yes. Have to say you're abilities to compile Zeev -> formal
declaration are pretty amazing :)
Zeev
> On 17 בפבר׳ 2015, at 08:20, Sara Golemon <poll...@php.net> wrote:
>
>> 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
