Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64879
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nGzPmmGW+R3V5F50ff_QxqUWTrORg93AQaXQ4u07Wj8Pw@mail.gmail.com>
References: <B5.40.02940.19BA0F05@pb1.pair.com>
	<CAF+90c-OgXu+HXVCvQ8=8mtP4DtBfm+m5YZux8yp2b5+Wofegw@mail.gmail.com>
	<50F0FB3B.2090509@sugarcrm.com>
	<CAAyV7nGzPmmGW+R3V5F50ff_QxqUWTrORg93AQaXQ4u07Wj8Pw@mail.gmail.com>
Date: Fri, 11 Jan 2013 22:59:15 -0800
Message-ID: <CAKOpQSy1C3a0bisBS8LLDCKoKCOutjXW4M1J0Q9nQ1jyahhRYA@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0447f3dc41a48804d311f36b
Subject: Re: [PHP-DEV] [VOTE] array_column() function
From: kris.craig@gmail.com (Kris Craig)

--f46d0447f3dc41a48804d311f36b
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jan 11, 2013 at 10:53 PM, Anthony Ferrara <ircmaxell@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

--f46d0447f3dc41a48804d311f36b--