On Fri, Jan 11, 2013 at 10:53 PM, Anthony Ferrara <[email protected]>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