Re: Re: cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h

Moriyoshi, First of thank you for taking the time to provide examples regarding the issues you are demonstrating. I've looked at a number of different applications and have not found a functionality breakage due to this change. While your example does show a change, I am not convinced (sorry) that it is an adverse one, type-different comparison is always tricky and not entirely reliable and I think demonstrates more of a corner-case situation. I think our best option at this time is to release 5.2.9 as quickly as possible as it introduces a number of crucial fixes and if your comments are validated via user feedback we can adjust the values with 5.2.10 that can be repackaged fairly rapidly. IMHO the current functionality is desired and is acceptable. Ilia Alshanetsky On 26-Feb-09, at 1:58 PM, Moriyoshi Koizumi wrote:

Robin Burchell wrote:

On Thu, Feb 26, 2009 at 5:21 PM, Moriyoshi Koizumi <mozo@mozo.jp> wrote:

So, in what point do you guys think of this change as valid? Moriyoshi

Is there any known examples of code broken by this, or is it a more academic than practical problem? <snip>

That's indeed a practical problem. 1. array_unique() has never been supposed to handle values other than strings. That's how bug #10658 is handled. http://bugs.php.net/10658 See also: http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/array/functions/array-unique.xml?revision=1.16&view=markup 2. the results are inconsistent between SORT_STRING and SORT_REGULAR when the items are a mixture of different types. <?php $objs = array( "0x10", 16, true, "true", ); var_dump(array_unique($objs, SORT_REGULAR)); var_dump(array_unique($objs, SORT_STRING)); $objs = array( "0x10", true, 16, "true", ); var_dump(array_unique($objs, SORT_REGULAR)); var_dump(array_unique($objs, SORT_STRING)); ?> I could hardly imagine what would show up. Do you? array(1) { [0]=> string(4) "0x10" } array(4) { [0]=> string(4) "0x10" [1]=> int(16) [2]=> bool(true) [3]=> string(4) "true" } array(2) { [0]=> string(4) "0x10" [3]=> string(4) "true" } array(4) { [0]=> string(4) "0x10" [1]=> bool(true) [2]=> int(16) [3]=> string(4) "true" } 3. the result can be unreasonable even with SORT_REGULAR As the equality of the object is only determined by member-wise comparison, there must be cases where the behavior is not acceptable: <?php class Foo { public $a; function __construct($a) {

       $this->a = $a;

} }; $objs = array( new Foo(1), new Foo("2e0"), new Foo(2), new Foo(3) ); var_dump(array_unique($objs, SORT_REGULAR)); ?> This yields: array(3) { [0]=> object(Foo)#1 (1) { ["a"]=> int(1) } [1]=> object(Foo)#2 (1) { ["a"]=> string(3) "2e0" } [3]=> object(Foo)#4 (1) { ["a"]=> int(3) } } while the second item is semantically not expected to be equal to the third. Moriyoshi --PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php