Andrei,
I think Moriyoshi has a point here there are several reports by people
who are affected by this, I think it makes sense to leave the
introduced functionality as is in 5.3/6, but for PHP 5.2 it probably
should be rolled back.
Ilia Alshanetsky
On 14-May-09, at 2:21 PM, Moriyoshi Koizumi wrote:
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
