> On 19 Nov 2014, at 18:28, Anatol Belski <anatol....@belski.net> wrote:
>
> On Wed, November 19, 2014 15:49, Andrea Faulds wrote:
>>
>>> On 19 Nov 2014, at 08:33, Anatol Belski <anatol....@belski.net> wrote:
>>> 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
?
I see no numbers?
> 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.
It’s not meant to cover all scenarios. It’s meant to failsafe on edge cases,
rather than producing apparently valid values which the user didn’t actually
intend (so “N/A” won’t become 0).
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
