Is there any chance of revisiting this issue? I mean, to change the default back to SORT_STRING. We now have a couple more reports regarding this:
http://bugs.php.net/47370#c147594 http://bugs.php.net/48115 Regards, Moriyoshi On Fri, Feb 27, 2009 at 8:30 AM, Ilia Alshanetsky <i...@prohost.org> wrote: > 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 <m...@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 >> > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
