On Fri, Jan 11, 2013 at 10:53 PM, Anthony Ferrara <ircmax...@gmail.com>wrote:
> 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 > What do you believe is the biggest loss incurred by adding a function that is useful but does not fit any of the three criteria you listed? Personally, I can't really think of one. I think it's more important to focus on consistency between functions (arguments order, etc) and clear documentation (which could be more difficult with a ton of array-related functions to scroll through, but that could be mitigated by organizing them into alphabetized subgroups). --Kris
