Re: Re: array_change_key_case()? key_exists()?

On Sun, 11 Nov 2001, Edin Kadribasic wrote: > Jeroen what you did was completely irresponsible. Without even starting a > discussion about whether a function is needed or not you take steps to > undocument them?!? Although I did 'undocument' them, I did so only __temporarily__ (otherwise I'd have removed it really, not placed it inside a comment). The one and only reason to do so, is to prevent a BC problem in the case it turns out that this function will be changed/removed. Wether or not this will happen, is something I wanted to discuss -- the problem is simply that it'd be a lot harder to change function if it's documented, so I merely intended to postponed the documentation. As soon as - after discussion - it is decided that this function will stay, the comment marks should be removed. I'm only asking: let's discuss the function itself first. > I added array_change_key_case to address issues of making PEAR::DB truly > portable since different db backends have different conventions on returning > the case of column names. How else would you make an application that is > supposed to run on both Oracle in Postgres using asoc arrays as return > values? Or process the results of getallheaders() function. This function can easily be written in userland, using foreach. Of course, it's not as easy as this function, but after all, what this function does is nothing else as: $ret = array(); foreach ($input as $key => $value) { $ret[strto(upp|low)er($key)] = $value; } Which is also mentioned on pear ML. The point is performance - the function in PHP is claimed to be about twice as fast. The performance tests though don't convince me: there are database queries in the loop too! A proper test would test this function only, and also correct for the loop overhead itself. I'm now creating such a test, to see the real difference. Slightly offtopic: And in the case of Pear::DB, the function is used for arrays consisting of column names, typically 5-10, usually at most a few dozen items large -- not really warranting a new function IMO. But even if it turns out that it's performancewise a lot better: PHP simply hasn't got the performance of C, and you cannot and IMO should not create functions in C just because it's faster: you'd better write the whole application in C if performance is of such a concern. Or fix PHP if it's having a performance problem in specific cases. But my biggest con against this function is that it is too specific. If such a function is to be added, add array_keys_walk or something similar, that function can be used in more than two places. --Jeroen Jeroen van Wolffelaar Jeroen@A-Eskwadraat.nl http://jeroen.A-Eskwadraat.nl