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
