Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:11738
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20040730153406.02ec00f0@127.0.0.1>
Date: Fri, 30 Jul 2004 15:39:19 -0700
To: Marcus Boerger <helly@php.net>,John Coggeshall <coogle@coggeshall.org>
Cc: internals@lists.php.net,John Coggeshall <john@coggeshall.org>
In-Reply-To: <768086459.20040727214559@marcus-boerger.de>
References: <Pine.LNX.4.44.0407271441420.14816-100000@coggeshall.org>
 <Pine.LNX.4.44.0407271441420.14816-100000@coggeshall.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Sorting Bug / Wrong behavior?
From: andi@zend.com (Andi Gutmans)

How would you expect the sort function to behave on the following:
array(true, false, 0, 1)?
It is a different way of looking at the same problem and you are likely to=
=20
hit this anytime you start comparing/sorting different data types.
In general, I don't think it makes very much sense to fix the comparison=20
operator for these special cases.
PHP has always done this kind of type juggling and you would be changing a=
=20
lot of its behavior.
I suggest that when you do try and sort an array with different kind of=20
data you define your own sorting callback function.
Making special cases for each such case in the compare function will not=20
only change behavior but it will slow down the already "too big for my=20
taste" compare function.
I know it's not the answer John was hoping for (I promised him to look into=
=20
it more deeply when I'm back from OSCON) but after doing so and thinking=20
about it, I think we'd be going in a direction which wouldn't be good.
I have a feeling this might also not give you the expected behavior for=20
something like array(0, "-1") but I haven't actually ran it.

Andi

At 09:45 PM 7/27/2004 +0200, Marcus Boerger wrote:
>Hello John,
>
>Tuesday, July 27, 2004, 9:48:28 PM, you wrote:
>
>
> > Consider the following:
>
> > <?php $a =3D array('a', 'b', 'c', 'a'=3D>0, 'b'=3D>1, 'c'=3D>2);
> >       sort($a);
> >       print_r($a);
>?>>
>
> > This produces a bogus output:
>
> > Array
> > (
> >     [0] =3D> a
> >     [1] =3D> b
> >     [2] =3D> 0
> >     [3] =3D> c
> >     [4] =3D> 1
> >     [5] =3D> 2
> > )
>
>
> > Notice how 0 and c are switched incorrectly. Attached is a patch to
> > zend_operators.c that fixes it.
>
>
>The current order simply makes no sense at all.=B4The following though=
 would:
>0 a b c 1 2   // zero dirst, then strings then numbers
>a b c 0 1 2   // strings first, then numbers
>0 1 2 a b c   // numbers first, then strings
>
>and btw, john you forgot the patch, it is attached here.
>The one provided does the 2nd which means we only ensured
>0 is treated un the same way other numbers are.
>
>Best regards,
>  Marcus                            mailto:helly@php.net
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php