Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12078
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Reply-To: john@coggeshall.org
To: sterling@apache.org
Cc: Andi Gutmans <andi@zend.com>, Marcus Boerger <helly@php.net>,
	John Coggeshall <coogle@coggeshall.org>, internals@lists.php.net
In-Reply-To: <24e5f3b70408101219286cd6d@mail.gmail.com>
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>
	 <24e5f3b70408101219286cd6d@mail.gmail.com>
Content-Type: text/plain; charset=
Message-ID: <1092166158.12209.9.camel@unix-101-34.hq.communityconnect.com>
Mime-Version: 1.0
Date: Tue, 10 Aug 2004 15:29:18 -0400
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Sorting Bug / Wrong behavior?
From: john@coggeshall.org (John Coggeshall)

I didn't realize that completely inconsistent behavior was no longer
considered a bug, and this edge case is certainly inconsistent with the
behavior of any other set of values sorted. Using the BC reasoning when
something is broken (i.e. it's not a bug, its a "feature") makes even
less sense.

John

On Tue, 2004-08-10 at 15:19, Sterling Hughes wrote:
> 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 to
> > 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 into
> > 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.
> > 
> > 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 = array('a', 'b', 'c', 'a'=>0, 'b'=>1, 'c'=>2);
> > > >       sort($a);
> > > >       print_r($a);
> > >?>>
> > >
> > > > This produces a bogus output:
> > >
> > > > Array
> > > > (
> > > >     [0] => a
> > > >     [1] => b
> > > >     [2] => 0
> > > >     [3] => c
> > > >     [4] => 1
> > > >     [5] => 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.´The 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
> > 
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> > 
> >