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