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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> > >--
> > >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
> >
> >
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
