Hi all,
In preparation for restarting the discussion on the strict operators RFC, I'm critically looking at cases where no TypeError is thrown, but the behavior changes instead.
Comparing two arrays using == is particularly fuzzy at the moment. An array in PHP is actually an ordered map. Using == will compare the operands as unordered maps. This is a useful feature, but maybe not generally expected. In addition == applies recursively, so type juggling is done on all elements of the array. Objects within the array are compared on equality rather than identity.
It's not possible to compare arrays as unordered maps without type juggling and by object identity. Similarly, it's not possible to compare arrays as ordered maps but with type juggling and by object equality. For example;
['x' => 1.0, 'y' => 2.0] == ['y' => 2.0, 'x' => 1.0]; // true
['x' => 1.0, 'y' => 2.0] === ['y' => 2.0, 'x' => 1.0]; // false because of key order
['x' => 1.0, 'y' => 2.0] == ['x' => 1, 'y' => 2]; // true
['x' => 1.0, 'y' => 2.0] === ['x' => 1, 'y' => 2]; // false because no type juggling
The RFC touches this subject but doesn't properly solve it. The example above still applies when using strict operators.
Additionally comparing a string to a number would always give a TypeError. Always returning false when comparing operands of different types (like in other languages) would return in too many cases where the behavior changes. The same could be said for elements of an array. It's not uncommon to compare numeric string to numbers (int/float) and preferably behavior shouldn't change in that case. To achieve this it's possible to throw an error if the types of two elements with the same key don't match. But I believe many would consider this unexpected and unwanted behavior, especially in combination with the first issue discussed.
The same issues also apply (to some extend) to objects. The behavior of two objects with numeric string and a number would change with strict operators.
Allowing comparison between a numeric string and a number would solve some of the issues, but undermine the concept of the RFC since it would mean throwing an error based on the value, rather than just the type. Additionally, it wouldn't solve the issue completely.
Any thoughts on this are appreciated.
Thanks,
Arnold
Arnold Daniels - Chat @ Spike [h4jnw]