Phpinspectionsea: Option to disable type unsafe comparison inspection with objects / arrays

[AllenJB]

The === (strict equals) vs == (non-strict equals) comparison takes on different meaning when comparing objects (must be same instance) and arrays (keys / values must be in same order).

As such, I would like the option to disable this inspection when either both values being compared are an object or both values being compared are an array.

It should be noted that comparing an empty array with null when using == will still return true, but comparing an "empty" object with null will not (strict_types does not affect the result of this comparison). Hence why I suggest this should be an option. Perhaps a separate inspection / option might be warranted for cases where one or both values might be nullable?

$a = [];
$b = null;
var_dump($a == $b);

$a = (object) [];
$b = null;
var_dump($a == $b);

Results in:

bool(true)
bool(false)

(3v4l for the above: https://3v4l.org/gg1ot )

References:

• http://php.net/manual/en/language.oop5.object-comparison.php
• http://php.net/manual/en/language.operators.array.php

[rentalhost]

I don't know if I should agree with that.

Your first example you could just do something like count($a) === 0, for instance, and make it explicit.

[DarkMukke]

I agree with @rentalhost, the whole === vs == argument is so that you know exactly what you are testing for, null is nothing, $a is an empty array which is not nothing.

[kalessil]

I'm not really following, what are we talking about here (I'm preparing a release, so my focus suffers)?
Can anyone explain what is needed/broken/smth. else?

[DarkMukke]

@kalessil this is an edge case where you would want to use == and not === when comparing values that PHP automatically converts. Eg, [] == null but [] !== null

@rentalhost and me are arguing that it isn't a strict type compensation, which is precisely why you should use === or no = at all.

In my opinion this is a case just falls out of scope and should not be fixed or have an exception added for.

[kalessil]

Agree with @DarkMukke, we shouldn't change current behavior.
IMO, the inspection currently forces to deal with types in the right way.