On Wed, November 19, 2014 15:49, Andrea Faulds wrote:
>
>> On 19 Nov 2014, at 08:33, Anatol Belski <anatol....@belski.net> wrote:
>>
>>
>> while briefly looking through the conversion examples, i see some weird
>> results
>>
>> string(5) “31e+7” - shouldn't this be valid for int?
>
> The trend seems to be to consider things with exponents or decimal points
> as floats. Even though there’s a case for supporting it for ints, (int)
> and intval() don’t work with exponents, so to_int() shouldn’t either.
>
>> string(4) “0x10” - hex, but that's int, no?
>
> Supporting hex is a rather obscure use-case. Also, (int) and intval()
> don’t support it.
>
>> string(3) “010” - octal, but that's int, no?
>
> While allowing leading zeroes would be nice, octal causes problems. In
> particular, 0-prefixed strings aren’t handled consistently. Some things
> deal with them as decimal, others deal with them as octal. Because the
> user’s intent isn’t clear, we can’t support them, and I assume this is why
> FILTER_VALIDATE_INT doesn’t support them.
>
>
>> string(4) “10.0” - this would be casting to 10, so int valid
>
> Allowing .0 for an int doesn’t feel right. What do we do for “10.01”?
> Reject
> it? That seems rather arbitrary when we would be allowing “10.00”. So it’s
> not accepted.
>
>> object(Stringable)#2 (0) {} - and similar actually, what if _toString()
>> returns some int/float literal? that should pass as well, no?
>
> __toString() always errors if it doesn’t return a string, I see no reason
> to change that.
But in the other cases it converts strings to numbers. I mean like
class A {function __toString(){return '10';}} $a = (string) (new A);
//numeric literal
>
>> Generally I'd say no to this RFC. The current casting is not perfect,
>> but as for me - the one suggested is highly questionable as well. IMO as
>> long as there are no proper strict types in PHP, any other rule set for
>> casting would be just another coordinate system for the same, which
>> isn't worth while at least.
>
> Something like this RFC is a necessary prerequisite for strict types.
> Without it, there’s not a convenient way to do a safe conversion. If we
> just add strict types, people will blindly use (int) or intval() and
> magically, garbage input will be transformed (through the magic of
> ignoring everything in the string that doesn’t look like an int) into
> apparently sane input and apps will do dangerous things when presented
> with bad user input.
>
> --
> Andrea Faulds
> http://ajf.me/
>
IMHO it's a new rule set around the old thing. There's no way to foresee
all the scenarios. Say I expect an an input to be less than 3. It's up to
a programmer whether to check that the input is (int)'3' > 3 and give up,
or to try sscanf('2e+22', '%f')[0] > 3. Even not talking about regex.
There are already mechanisms allowing to implement that, customizable to a
high level and usually one can come up with them. Maybe that rule set
would sometimes let spare a line, still it depends on concrete use case.
Regards
Anatol
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
