> > Ported to https://github.com/Ocramius/array_change_keys-benchmark, thanks! >
I've updated the RFC's benchmarks based on your tool. They confirm that array_change_keys is faster than array_combine but slower than foreach (in most cases). Thanks for helping with this! > No, but I really don't care about the other functions. If something > doesn't support a `Traversable` in today's jungle of Generators and > asynchronous processing. > While generators and async processing are nice, I don't think that means we have to avoid work that doesn't fall under that umbrella. Or Is there perhaps something unique about this particular function that warrants Traversable support whereas other functions don't? > 3. Purpose of the array_*() function is immediately obvious. >> > > Disagree, as mentioned in few edge cases in other responses (something > about numerical keys, IIRC: can't find the actual reply) > I believe you're referring to the questions about returning null, invalid, or duplicate keys. As I mentioned in my responses to those questions, array_change_keys() was expressly designed to behave *EXACTLY* like existing functions (such as array_flip): - Returning null as a key is not allowed (array_flip disallows this). - If you return a duplicate key, only the last value to return it will be kept (just like calling array_flip with duplicate values or running: $arr['foo'] = 1; $arr['foo'] = 2;) Somebody else asked whether they could "return null" to use an automatic numeric key - I responded "no" because "$arr[null]" is not the same as "$arr[]". *Again, this RFC does NOT introduce any new edge cases or quirks.* I'd therefore respectfully ask that you re-consider this. > Function composition can be applied also with a userland implementation. > My main issue with this is that it doesn't need to exist in *core*. Doesn't > mean that it can't exist in userland ;-) > One could argue that array_change_key_case(), array_column(), random_int(), password_hash(), and others don't strictly need to exist in core either. However, they were all included because someone (or some group) felt that they provided enough value to PHP developers and/or that their usefulness outweighed the hassle of a userland implementation. All I ask is that we give this RFC the same consideration - and if you still feel the same I fully accept that :) I appreciate the feedback as always and have updated the RFC with several of these discussion points. Colin
