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

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 <ilia@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 <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 >> > >