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

From: Date: Tue, 22 Sep 1998 17:42:26 +0000
Subject: Re: Bug #765: new kusort() function (or similar)
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-1411@lists.php.net to get a copy of this message
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). > > > What I do is, I scan a directory for files which contain data about > bugs. The > name files are split to extract info about package, set and test. I put > all data > I need in an array where set and test are keys to values which come > from inside the files. > > 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. 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. 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. Zeev -- ----------------------------------------------------- Zeev Suraski <zeev@php.net> For a PGP public key, finger bourbon@netvision.net.il -- 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

« previous php.dev (#1411) next »