I'm just wondering why you appreciate the new behavior. Are there
still any positive reasons to incorporate the change? Could anyone
provide some example that the new behavior works better than the
original?
By the way, I noticed that SORT_REGULAR behaves differently than
SORT_STRING if the items are all strings.
<?php
$objs = array(
"0x1",
"1",
);
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
?>
Furthermore, the code that depends on __toString() also won't work
properly anymore. It's pretty much possible that an user uses the
function for semantic comparison.
<?php
class Foo {
public $a;
function __construct($a) {
$this->a = $a;
}
function __toString() {
return "1";
}
}
$objs = array(new Foo("1"), new Foo("2"), new Foo("3"));
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
?>
I think it's where the word BC break is appropriate to describe these
situations.
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
