Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12077
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <24e5f3b70408101219286cd6d@mail.gmail.com>
Date: Tue, 10 Aug 2004 12:19:33 -0700
Reply-To: sterling@apache.org
To: Andi Gutmans <andi@zend.com>
Cc: Marcus Boerger <helly@php.net>, John Coggeshall <coogle@coggeshall.org>, 
	internals@lists.php.net, John Coggeshall <john@coggeshall.org>
In-Reply-To: <5.1.0.14.2.20040730153406.02ec00f0@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
References: <Pine.LNX.4.44.0407271441420.14816-100000@coggeshall.org>
 <Pine.LNX.4.44.0407271441420.14816-100000@coggeshall.org> <5.1.0.14.2.20040730153406.02ec00f0@127.0.0.1>
Subject: Re: [PHP-DEV] Sorting Bug / Wrong behavior?
From: sterling.hughes@gmail.com (Sterling Hughes)

i don't think sort() should be changed - this is how php works, for
better or sometimes worse, changing it any other way would break BC,
and it doesn't make much sense.

-Sterling

On Fri, 30 Jul 2004 15:39:19 -0700, Andi Gutmans <andi@zend.com> wrote:
> 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 t=
o
> 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
> operator for these special cases.
> PHP has always done this kind of type juggling and you would be changing =
a
> lot of its behavior.
> I suggest that when you do try and sort an array with different kind of
> data you define your own sorting callback function.
> Making special cases for each such case in the compare function will not
> only change behavior but it will slow down the already "too big for my
> taste" compare function.
> I know it's not the answer John was hoping for (I promised him to look in=
to
> it more deeply when I'm back from OSCON) but after doing so and thinking
> 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
> something like array(0, "-1") but I haven't actually ran it.
>=20
> Andi
>=20
>=20
>=20
> 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 w=
ould:
> >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
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20
>