Stas, This is a great illustration of different visions we have here. On one > hand, we have practical, immediate feature that covers a clear use case > and does not add any constructs or complexity to the core language and > services immediate need, covering several lines of frequently > encountered boilerplate code with one function. > > On the other hand, we have a possibility to have in the future a > fashionable syntax, which is a bit better, more concise and "cool > looking" expression for what foreach already can do. > > So, my "vision", for example, is that while there's nothing wrong with > "cool" language syntaxes and adding them, we should not reject simple > practical solutions for them. This is what was done in PHP for years, > and I think it is one of the reasons PHP is a great tool for the > programmer. Just trying to make my "vision" more clear :) >
I definitely agree with you here. Voting against a library feature because of a language future that's not even proposed yet is a bit... Odd... With that said, I'm inclined to vote against this, but for a different reason. (Note I said inclined, I haven't voted yet because my mind isn't made up yet completely)... I am concerned about library bloat. We already have 76 array functions: http://us3.php.net/manual/en/ref.array.php IMHO, a new function should be added in one of three cases: 1. It's hard to do in user-land Meaning that it takes non-trivial code (30 to 40 lines, difficult error handling, complex algorithms, etc). Considering that you can do the same thing as this in 3 lines of user-land code without error handling, and 6 with error handling, I don't think it qualifies. Contrast that to something like sort() which actually is a non-trivial algorithm to do efficiently... 2. It's not performant to do in user-land. Some things are just plain more efficient to do in C than PHP. Something like a quicksort. But in this case the trivial PHP implementation should run in O(n), just as C does. And since C is doing hashtable access for everything, I can't see that this is going to be significantly more efficient in C (at least for common sizes of arrays, say less than 10k elements). If there are benchmarks that prove this point wrong, I'll gladly concede it... 3. It's extremely common. All other things aside, it would still belong in core IMHO if it's an extremely common need. That way we can help common implementation problems and make life easier. Pretty self explanatory. >From what I can see this new function doesn't fit any of those three to a significant enough extent. All three are definitely subjective, but I'm leaning towards a no vote because I just don't feel there's enough justification for the new function when weighted against the bloat factor... My $0.02... Thoughts? Anthony
