Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106208
To: internals@lists.php.net
References: <c-17aa9-jxbttytv-fj6p6s=1xtnjis@2.gethop.com>
 <CAF+90c9Y8A8eyH-Cfx3_dj=XTpw3JXboFfNVB+9G3+=bE2hFsg@mail.gmail.com>
 <CANZOY=AeQDNHD=XsCqPpvtN+ZKhPZhsynwzhUznBtm8-rPky0Q@mail.gmail.com>
Message-ID: <5f3eb364-82f1-ce9e-8cff-34b74687c335@mabe.berlin>
Date: Thu, 11 Jul 2019 00:24:27 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <CANZOY=AeQDNHD=XsCqPpvtN+ZKhPZhsynwzhUznBtm8-rPky0Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Subject: Re: [PHP-DEV] [RFC] Strict operators directive
From: dev@mabe.berlin (Marc)

Hi,


On 10.07.19 23:37, Arnold Daniels wrote:
>> * I also find it somewhat odd that you can't write something like "$obj !=
>> null" anymore, only "$obj !== null".
>>
> To check against null, it's better to use !==. For objects (and resources)
> using `!= null` is ok, but for other types, it's currently not. For
> example; `[] == null` gives true.

I would argue that two operands will not be the same if they are of 
different types (except for int/float).

Means 0 == "" and 0 == "0" will both be false but 0 == 0 and 0 == 0.0 
will be true.

Note: In my opinion int/float check should also make sure that there is 
no data loss on comparing a very bit integer to a float. In this case 
they should not be equal.

>
>
>> * I think the "solution" to the last three points is a) only support
>> numbers in relational operators (<,<=,>,>=,<=>) and throw TypeErrors
>> otherwise (maybe modulo provisions for object overloading) and b) allow
>> comparing any types in == and !=, without throwing a TypeError. The
>> question "Are 42 and 'foobar' equal?" has a pretty clear answer: "No they
>> aren't", so there is no need to make this a TypeError (while the question
>> "Is 42 larger than 'foobar'?" has no good answer.) I believe doing
>> something like this would roughly match how Python 3 works. (Edit: I see
>> now that this is mentioned in the FAQ, but I think it would be good to
>> reconsider this. It would solve most of my problems with this proposal.)
>>
> Besides the argument in the FAQ, having the == and != return do a type
> check, means there are a lot more cases where the behavior changes rather
> than that a TypeError is thrown. Currently `"foobar" == 0` returns true,
> but this would make it return false. So would `1 == true`, `"0" == 0` and
> `"0" == false`. To reduce the cases where the behavior changes to a
> minimum, it's better to throw TypeErrors for == and !=.

I thing this goes hand in hand with the empty check like empty("0") is 
true but empty("00") is false.

I couldn't find how/if this will change with this RFC.


>
>
>> * String increment seems like a pretty niche use case, and I believe that
>> many people find the overflow behavior quite surprising. I think it may be
>> better to forbid string increment under strict_operators.
>>
> Ok
>
>
>> * A similar argument can be made for the use of &, | and ^ on strings.
>> While I have some personal fondness for these, in practical terms these are
>> rarely used and may be indicative of a bug. I think both for string
>> increment and string and/or/xor it may be better to expose these as
>> functions so their use is more explicit.
>>
> These operators make it very easy to work with binary data as strings in
> PHP. In other languages you have to work with byte arrays, which is a major
> pain. They're also very intuitive; `"wow" & "xul"` is the same as
> `chr(ord('w') & ord('x')) . chr(ord('o') & ord('u')). chr(ord('w') &
> ord('l'))`. I think these should stay.

I do agree here. Even if working with binary strings isn't most common 
in PHP web development I actually use these for bitsets.

But I have a note here that bit shifting currently does not work with 
binary strings (tries to cast binary string to integer) and even if it 
would shift the binary string the >> is designed to keep the first bit 
as a positive/negative flag which of course does not make sense for 
binary strings.

In my opinion the bit shifting operators should accept and work well 
with binary strings. I don't see a reason why it's performing a type 
cast here.


>
>
>> Regards,
>> Nikita
>>
> Arnold
>

Marc