Re: Bug #765: new kusort() function (or similar)

On Tue, 22 Sep 1998, Zeev Suraski wrote: > Date: Tue, 22 Sep 1998 19:42:26 +0200 (IST) > From: Zeev Suraski <bourbon@netvision.net.il> > To: Home Libs <libs@cybercable.tm.fr> > Cc: php-dev@lists.php.net > Subject: Re: [PHP-DEV] Bug #765: new kusort() function (or similar) > > On Tue, 22 Sep 1998, Jean-Marc Libs wrote: > > > My point is, I don't believe it is fairly rare. I may be biased because > > of what > > I intend to do. I explain what I do below so you can decide if it is a > > legit > > use of PHP or if I should totally redesign the script. > > It will have to be redesigned later with database use anyway when I have > > free > > time (yeah right). > > [snip] > > > > So my key is at the same time a test number and also a string, which I > > get from > > the filename and which I use later to construct other filenames. > > > > Then I can nicely separate collection of data and display of data. > > To display, I just ksort() on all levels of my multi-dimensional array > > and loop on the keys to format the data, reconstruct filenames to put in > > URL links, etc... > > > > The only glitch is, ksort does not really sort the keys in order. Yet I > > feel > > this is a fairly standard use of associative arrays. If the keys I use > > do not > > have any meaning to me (that is, if I have to append stuff to change the > > behaviour of ksort), I might as well use fully numerical keys and > > reformat > > them into the proper strings later on. > > It might even speed up the script. But it just defeats the purpose of > > associative arrays as I understand them. > > > > > > This is what I call inelegant: changing the data to suit the data > > manipulation functions and then changing it back. > > > > I hope I cleared up the issue, > > > > I just looked a bit in the code. From the comments in > > array_data_compare, I > > gather that kusort() is more likely than a variant of ksort() doing what > > I'd > > like. > > > Well, I still think that people don't usually store fixed length numbers > in arrays, that is, if they store numbers and want to traverse them > sequentially, all they store is numbers, and not numbers with leading > zerros as well. Actually, it's the other way round. I am using fixed-length strings as keys, some of which get interpreted as integers by PHP. Then I wish to do an alphabetic sort on the keys, and ksort separates some keys (those beginning by 1, which look like numbers) from the others. > Because of this, implementing a builtin function that > will behave just like ksort() except it'll convert string indices to > numbers seems redundant to me. I thought it would be the other way round: treat everything as strings for sorting purposes. > You don't have to redesign your script at all. You can easily implement > any sort order you want using the usort(): > > function numeric_compare($i1,$i2) > { > return (int) $i1 - (int) $i2; > } > > usort($array, "numeric_compare"); > > usort() was added in version 3.0.3, so you may need to upgrade before you > can use it. If you do, wait up for 3.0.4, it should be out today. I know about usort() and I considered it. But it sorts on values and I sort on keys. It still does not seem redundant to me. That's why I filed this request for kusort which does for ksort what usort does for sort. I already use 3.0.3 and I'd happilly install 3.0.4 and test it out when it's out, but it won't help. Cheers, Jean-Marc -- "While you're waiting, read the free novel we sent you. It's a Spanish story about a guy named `Manual'" - Dilbert -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net