Hi,
> On 8 Feb 2015, at 03:52, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
>
> On 02/07/2015 09:51 PM, Andrea Faulds wrote:
>>> tan(1);
>>> echo strstr("test", "est", 1);
>>
>> Banning int->float and float->int is both a pain point and sometimes a
>> life-saver. It’s annoying that tan(1) doesn’t work. On the other hand, you
>> discover if your ints floats would be silently truncated (as I did with
>> PictoSwap).
>>
>> I wouldn’t say that int->string not working is a problem, though. Seeing
>> something like strstr(“test”, “est”, 1); is rather confusing. Looking at it,
>> I’d think the third parameter is some sort of number for you to want to pass
>> an integer to it. If I want a string, I’ll use one.
>
> This isn't int->string. This is int->boolean. The 3rd arg to strstr() is
> a boolean and passing 1 instead of true makes it blow up. It is very
> very common for people to pass 0 or 1 in place of true/false to all
> sorts of things in PHP.
Oh, my bad, I looked up strtr and not strstr.
I’m not sure that disallowing implicit integer->boolean conversion is bad,
though. That conversion will discard all data except whether the value is
non-zero. If you opt in to strict typing, then you have chosen to always use
the correct types.
>
>> Yes, the RFC is somewhat inaccurate in that respect. It is per-file in one
>> sense (like encoding, but unlike ticks, it has no effect on the including or
>> included files). However, it technically affects the remainder of the file,
>> not the whole file.
>
> Well, no, not the remainder of the file either since it can be switched
> again. It only affects the part of the file between declares if there is
> a second one.
Sure, that’s true, the option can be changed more than once.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
