[VOTE] array_column() function

Nikita Popov

13 years ago

On Sat, Jan 12, 2013 at 1:17 AM, Ben Ramsey <ramsey@php.net> wrote:

> I've opened voting for the array_column() function RFC.
>
> You can vote at https://wiki.php.net/rfc/**array_column#voting<https://wiki.php.net/rfc/array_column#voting>
>
> Regards,
> Ben
>

Voting no, because - even though I like this feature in principle - I think
it's much better solved by introducing list comprehensions (which cover
this and many more cases in a consistent and elegant syntax), which is
something I have planned for 5.6.

Nikita

Arpad Ray

13 years ago

On Sat, Jan 12, 2013 at 12:21 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> Voting no, because - even though I like this feature in principle - I think
> it's much better solved by introducing list comprehensions (which cover
> this and many more cases in a consistent and elegant syntax), which is
> something I have planned for 5.6.

I'd love to see list/dict comprehensions in PHP :)

Arpad

Stas Malyshev

13 years ago

Hi!

> Voting no, because - even though I like this feature in principle - I think
> it's much better solved by introducing list comprehensions (which cover
> this and many more cases in a consistent and elegant syntax), which is
> something I have planned for 5.6.

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 :)

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Anthony Ferrara

13 years ago

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

Kris Craig

13 years ago

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

Levi Morrison

13 years ago

The real problem here (in my opinion) is that `array_filter` does not
pass the key information to the callback. If you could do that, you
could select columns that way.

Herman Radtke

13 years ago

On Sat, Jan 12, 2013 at 12:04 AM, Levi Morrison <morrison.levi@gmail.com> wrote:

> The real problem here (in my opinion) is that `array_filter` does not
> pass the key information to the callback. If you could do that, you
> could select columns that way.

I opened a PR with this feature, but it was rejected.

--
Herman Radtke
@hermanradtke | http://hermanradtke.com

Lars Strojny

13 years ago

Nope, it wasn’t rejected, there was simply no response for a really long time: https://github.com/php/php-src/pull/202

Am 14.01.2013 um 22:06 schrieb Herman Radtke <hermanradtke@gmail.com>:

Thomas Hruska

13 years ago

On 1/11/2013 11:53 PM, Anthony Ferrara wrote:

>>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

I can see a use-case for this but the PDO relationship is a poor reason
for having it.  The whole PDO thing threw me off such that I was in the
same boat as Anthony with the same thoughts.  Contrived examples aren't
helpful for passing a RFC.  Here is a more reasonable example:

echo implode(", ", array_column($myarray, 2));

It saves constructing a separate array or writing my own function in PHP
userland that comes with the risk of naming conflicts.  array_column()
is a handy shortcut to a process.  I've not thought about writing a PHP
userland function for this before because it generally only takes a
couple of lines of code.  This formalizes that process and simplifies code.

It isn't a function I'll necessarily use every day, but the above
example is more useful and will speak to more developers than the PDO
example will.

I have a separate recommendation that could eliminate the need for the
third optional parameter of array_column(), but I'll start another
thread on this list for it.

--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you might find useful.

http://cubiclesoft.com/

Nikita Popov

13 years ago

On Sat, Jan 12, 2013 at 6:57 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> > Voting no, because - even though I like this feature in principle - I
> think
> > it's much better solved by introducing list comprehensions (which cover
> > this and many more cases in a consistent and elegant syntax), which is
> > something I have planned for 5.6.
>
> 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.
>

Stas, I think you are misrepresenting this a bit. It's not about adding
something "cool looking", it's about adding a feature that solves *this and
many more* problems in a consistent way. A way that does *not* require to
add a new function for every single array manipulation.

I know that not everyone agrees with that philosophy, but I personally
don't like to add new features that can be easily covered by more general
solutions, or features that just represent a hack because the more general
solution isn't implemented yet. This is also the reason why I don't
particularly like your argument skipping proposal, because it's just a hack
around the lack of named arguments. The thing with the argument skipping
proposal is though that the alternative (named args) is pretty hard to
implement and we might not actually get them any time soon. Here it is
different as list comprehensions are more or less a triviality.

That's why I think that this is not necessary. It will be hopefully
properly handled in the future and until then this function is trivial
enough to just write it yourself. I don't see how we need yet another
array_ function for it.

But hey, just my opinion, not everyone has to agree with this :)

Thanks,
Nikita

Derick Rethans

13 years ago

On Sat, 12 Jan 2013, Nikita Popov wrote:

> On Sat, Jan 12, 2013 at 6:57 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:
>
> > 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.
> >
>
> Stas, I think you are misrepresenting this a bit. It's not about
> adding something "cool looking", it's about adding a feature that
> solves *this and many more* problems in a consistent way. A way that
> does *not* require to add a new function for every single array
> manipulation.
>
> I know that not everyone agrees with that philosophy, but I personally
> don't like to add new features that can be easily covered by more
> general solutions, or features that just represent a hack because the
> more general solution isn't implemented yet.

By more general you mean extra special new OO constructs? Sorry, but PHP
should also be useable by non-CS majors. And so what we have 76 (soon
77!) array functions?

> This is also the reason why I don't particularly like your argument
> skipping proposal, because it's just a hack around the lack of named
> arguments.

Argument skipping is a language construct, this just adds a new function
to the 2000 we already have. Quite a different matter.

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

Nikita Popov

13 years ago

On Sat, Jan 12, 2013 at 4:54 PM, Derick Rethans <derick@php.net> wrote:

> > I know that not everyone agrees with that philosophy, but I personally
> > don't like to add new features that can be easily covered by more
> > general solutions, or features that just represent a hack because the
> > more general solution isn't implemented yet.
>
> By more general you mean extra special new OO constructs? Sorry, but PHP
> should also be useable by non-CS majors. And so what we have 76 (soon
> 77!) array functions?
>

List comprehensions are in no way related to OO. At least no way I know
off. But in any case:

I apologize for what I wrote in the first mail in the thread. It was not
constructive to this discussion, because it only contained half of my
reasoning and I only mentioned the more controversial part.

What I should have said is this: I think that this is a very simple
function that can be easily implemented in userland and I just don't see
sufficient need or implementational advantages for it to be part of core
(see also Anthony's response). The note on list comprehensions should only
be relevant insofar that they would make this function even *less* useless
in the future.

Again, sorry for hijacking this thread.
Nikita

Stas Malyshev

13 years ago

Hi!

> Stas, I think you are misrepresenting this a bit. It's not about adding
> something "cool looking", it's about adding a feature that solves *this
> and many more* problems in a consistent way. A way that does *not*
> require to add a new function for every single array manipulation.

We already have a way that works with arrays without adding functions.
It's called foreach(). However, *some* ways of manipulating arrays are
encountered very frequently, and it is a long-standing tradition of PHP
to provide shortcut functions for such functionality.

> I know that not everyone agrees with that philosophy, but I personally
> don't like to add new features that can be easily covered by more
> general solutions, or features that just represent a hack because the

That's why I am talking about difference in visions. I prefer practical
solution for immediate needs, you think it is never needed as long as
there is a general solution and the practical need can be implemented
using it, even if the code will be longer and requires more work from
the person implementing it.

> That's why I think that this is not necessary. It will be hopefully
> properly handled in the future and until then this function is trivial
> enough to just write it yourself. I don't see how we need yet another

Most of array_* functions can be trivially written using foreach() or
some other form of loop. That, in my opinion, does not detract from
their usefulness. And if we look at the history of PHP, that has long
been the tradition.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Derick Rethans

13 years ago

On Fri, 11 Jan 2013, Stas Malyshev wrote:

> > Voting no, because - even though I like this feature in principle - I think
> > it's much better solved by introducing list comprehensions (which cover
> > this and many more cases in a consistent and elegant syntax), which is
> > something I have planned for 5.6.
>
> 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 wholeheartly agree with that!

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

Matt Pelmear

13 years ago

On 01/11/2013 04:17 PM, Ben Ramsey wrote:

> I've opened voting for the array_column() function RFC.
>
> You can vote at https://wiki.php.net/rfc/array_column#voting
>
> Regards,
> Ben
>

+1

I can't vote, but I support this RFC.

This is much, much simpler to use and easier to implement than most
other things I've been watching here recently (annotations, list
comprehensions), and I work with multiple teams that would definitely
benefit from this on a regular basis.

That said, I hate function aliases. Can't we have one or the other here,
not both? (array_column() vs array_pluck())

-Matt

Nikita Popov

13 years ago

On Sat, Jan 12, 2013 at 1:36 AM, Matt Pelmear <mjpelmear@gmail.com> wrote:

> That said, I hate function aliases. Can't we have one or the other here,
> not both? (array_column() vs array_pluck())
>

Agree fully on this part. If this is going to make it, then please,
*please* without aliases. array_column() is my preference here, because it
has some descriptive value, whereas I have no idea what "array pluck" is
supposed to be (and google doesn't give me much on it...)

Nikita

Peter Cowburn

13 years ago

On 12 January 2013 00:17, Ben Ramsey <ramsey@php.net> wrote:

> I've opened voting for the array_column() function RFC.
>
> You can vote at https://wiki.php.net/rfc/array_column#voting
>
> Regards,
> Ben
>

The "Status" for this RFC is still "Under discussion" and on the RFC
listing page it is the same. Is not changing those two things simply
an oversight?

Ben Ramsey

13 years ago

On 1/12/13 9:14 AM, Peter Cowburn wrote:

> The "Status" for this RFC is still "Under discussion" and on the RFC
> listing page it is the same. Is not changing those two things simply
> an oversight?
>

It was an oversight. I have corrected it in both places.

Derick Rethans

13 years ago

On Fri, 11 Jan 2013, Ben Ramsey wrote:

> I've opened voting for the array_column() function RFC.
>
> You can vote at https://wiki.php.net/rfc/array_column#voting

I'm liking this, why start with an function alias already when
introducing a new feature?

cheers,
Derick

Ben Ramsey

13 years ago

On 1/12/13 9:19 AM, Derick Rethans wrote:

> I'm liking this, why start with an function alias already when
> introducing a new feature?

I figured this would be a frequent question, and I was right. :-)

In earlier discussions (June 2012), when I first introduced
array_column(), much of the discussion revolved around the name and not
the functionality. I agreed with arguments for array_column() and
arguments for array_pluck(), so I added an alias.

Here's why I think the alias should be considered:

1) Userland PHP developers instantly recognize array_column(). It's
self-descriptive, and they know what it means.

2) Developers coming from other languages (Ruby, JavaScript, etc.) will
instantly recognize array_pluck(). It's what they'll be looking for to
do the same thing, but they won't be looking for array_column().

-Ben

Clint M Priest

13 years ago

My .02 cents here...

I'm used to array_pluck(), even when I first saw it I was like WTH is
that?  When you read the description though, 'plucking' is a verb which
describes the action the function is taking, while column is a noun and
does not describe the action the function is taking.

In fact I have my own userland array_pluck() function.

Ergo, array_column() doesn't make sense, array_get_column() might make
sense, while array_pluck() makes sense.

I'm fine with an alias or either one really, just pointing out the logic
of "pluck."

-Clint

On 1/12/2013 9:34 AM, Ben Ramsey wrote:

> On 1/12/13 9:19 AM, Derick Rethans wrote:
>> I'm liking this, why start with an function alias already when
>> introducing a new feature?
>
> I figured this would be a frequent question, and I was right. :-)
>
> In earlier discussions (June 2012), when I first introduced
> array_column(), much of the discussion revolved around the name and
> not the functionality. I agreed with arguments for array_column() and
> arguments for array_pluck(), so I added an alias.
>
> Here's why I think the alias should be considered:
>
> 1) Userland PHP developers instantly recognize array_column(). It's
> self-descriptive, and they know what it means.
>
> 2) Developers coming from other languages (Ruby, JavaScript, etc.)
> will instantly recognize array_pluck(). It's what they'll be looking
> for to do the same thing, but they won't be looking for array_column().
>
> -Ben
>

--
-Clint

Matt Pelmear

13 years ago

Hi,

On 01/12/2013 07:34 AM, Ben Ramsey wrote:

>
> 2) Developers coming from other languages (Ruby, JavaScript, etc.)
> will instantly recognize array_pluck(). It's what they'll be looking
> for to do the same thing, but they won't be looking for array_column().
>
> -Ben
>

When I have to write JavaScript (for example), I end up doing google
searches like "javascript php array_keys" and always find what I'm
looking for without a problem. I really think the alias just adds confusion.

Clint's argument for "pluck" being a verb and "column" being a noun
makes some sense to me, however "plucking" would imply, to me, that the
data is being removed from the source, as opposed to copied from it. As
google says: "Pluck: Take hold of (something) and quickly remove it from
its place".

Also, "array_column" is certainly consistent with other function names
in PHP (array_keys(), values(), key(), etc.), which also refer to a set
of data within the array data structure, whereas "pluck" sounds very
much like a carryover from Ruby and Prototype.


-Matt

Stas Malyshev

13 years ago

Hi!

> 2) Developers coming from other languages (Ruby, JavaScript, etc.) will
> instantly recognize array_pluck(). It's what they'll be looking for to
> do the same thing, but they won't be looking for array_column().

I say nuke the alias :) I like array_column (maybe because English is
not my native language and the word "pluck" sounds a bit weird for me -
never heard it being used outside of music lessons) but I prefer having
either to having both. Ruby developers will be capable to get what
array_column means, it's not that hard :)

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Galen Wright-Watson

13 years ago

On Sat, Jan 12, 2013 at 7:34 AM, Ben Ramsey <ramsey@php.net> wrote:

> On 1/12/13 9:19 AM, Derick Rethans wrote:
>
>> I'm liking this, why start with an function alias already when
>> introducing a new feature?
>>
>
> I figured this would be a frequent question, and I was right. :-)
>
> In earlier discussions (June 2012), when I first introduced
> array_column(), much of the discussion revolved around the name and not the
> functionality. I agreed with arguments for array_column() and arguments for
> array_pluck(), so I added an alias.
>
> Here's why I think the alias should be considered:
>
> 1) Userland PHP developers instantly recognize array_column(). It's
> self-descriptive, and they know what it means.
>
> 2) Developers coming from other languages (Ruby, JavaScript, etc.) will
> instantly recognize array_pluck(). It's what they'll be looking for to do
> the same thing, but they won't be looking for array_column().
>

As an alternative to an alias, what about a manual page for whichever name
isn't used that redirects or (like delete <http://php.net/delete>) refers
to the one that is used? Of course, this wouldn't help when someone is
searching or browsing through code. For #2, were you envisioning the
developer looking for a "pluck" function in the manual, browsing source and
coming across the function, searching (grep &c) the code for a "pluck"
function, or something else?

Peter Cowburn

13 years ago

On 12 January 2013 00:17, Ben Ramsey <ramsey@php.net> wrote:

> I've opened voting for the array_column() function RFC.
>
> You can vote at https://wiki.php.net/rfc/array_column#voting
>

I like the idea of this function, but have a few minor questions re.
the current implementation.

1. Why is this branch based on 5.3, rather than 5.4 or 5.5? Do you
want this to be part of 5.3? The RFC (in particular the vote question)
does not make it clear where/when you want this to be added.

2. The $columnKey argument "may be the 0-indexed number of the column
you wish to retrieve, or it may be the string key name for an
associative array."

When the nested arrays use numeric indices and the function is called
with a number, then this argument is not "the 0-indexed number of the
column" but rather the integer key (i.e., the $columnKey is always
specifying the key, regardless of integer or string).  Could the
description be updated to reflect that, if it is indeed the desired
behaviour?  Also, when the nested arrays are non-0-indexed should we
be able to somehow specify the column (rather than the key)? I have no
answer of my own for that last question!

3. It is not documented what happens when the $columnKey and/or
$indexKey are not present in the nested array, could this be added?
The current implementation appears to not include an item in the
resulting array if $columnKey is not present. If $columnKey is present
but $indexKey is not, a 0-based index is used in the current
implementation.

4. An example of what happens when the resulting array has overlapping
keys would not go amiss (though the behaviour is obvious).

5. Regarding the alias, so long as we clearly mention the word "pluck"
(or "array_pluck") on the documentation page, folks coming from other
languages should be able to find our implementation.  I'm not sure we
really need it as an actual alias, but have no strong opinion one way
or the other.

Overall, I'm liking this simple addition to the array library.

Levi Morrison

13 years ago

> 1. Why is this branch based on 5.3, rather than 5.4 or 5.5? Do you
> want this to be part of 5.3? The RFC (in particular the vote question)
> does not make it clear where/when you want this to be added.

Please, this is not a bug or security fix. It does not belong in 5.3.

Ben Ramsey

13 years ago

On 1/12/13 10:17 AM, Levi Morrison wrote:

>> 1. Why is this branch based on 5.3, rather than 5.4 or 5.5? Do you
>> want this to be part of 5.3? The RFC (in particular the vote question)
>> does not make it clear where/when you want this to be added.
>
> Please, this is not a bug or security fix. It does not belong in 5.3.
>

I must have misread the Git Workflow page of the wiki, which states:

"A patch will be applied to the oldest possible branch. If the Release
Manager of 5.3 accepts the change, commit it to the 5.3 branch. We will
use regular merging between the release branches."

I can submit a new pull request against the master branch, if that's
acceptable. This is intended for 5.5.

-Ben

Peter Cowburn

13 years ago

On 12 January 2013 16:41, Ben Ramsey <ramsey@php.net> wrote:

>
> I must have misread the Git Workflow page of the wiki, which states:
>
> "A patch will be applied to the oldest possible branch. If the Release
> Manager of 5.3 accepts the change, commit it to the 5.3 branch. We will use
> regular merging between the release branches."
>
> I can submit a new pull request against the master branch, if that's
> acceptable. This is intended for 5.5.
>

The wiki is a little unclear there. The "oldest possible branch"
against which this can be applied is, theoretically, PHP 5.5 according
to the release process that was agreed to. In all likelihood, it could
be added to 5.4 with the RMs consent. So the "oldest possible branch"
is going to be one of those, not 5.3 nor master.

One extra little detail that would be handy (at least for my own
considered use of this new function) would be able to utilise the
existing keys of the target array rather than relying on new 0-indexed
keys or values from sub-arrays.

$array = [
123 => ['Chuck', 'Norris'],
310 => ['Sylvester', 'Stallone'],
736 => ['Jason', 'Statham']
];

$first_names = array_column($array, 0, true); // 3rd param used as
"preserve keys" (default = false)
// [123 => 'Chuck', 310 => 'Sylvester', 736 => 'Jason']

The above is not really an issue, given array_keys() and
array_combine() [though one neat function call would be nice], but it
becomes most useful when the resulting array has fewer values than the
original. To take your example from the RFC:

$mismatchedColumns = array(
array(
'a' => 'foo',
'b' => 'bar',
'e' => 'baz'
),
array(
'a' => 'qux',
'c' => 'quux',
'd' => 'corge'
),
array(
'a' => 'grault',
'b' => 'garply',
'e' => 'waldo'
),
);

$b = array_column($mismatchedColumns, 'b', true); // 3rd param used as
"preserve keys" (default = false)
// [0 => 'bar', 2 => 'garply']

Note how that has keys [0, 2].

So the idea is to potentially change the $indexKey parameter from
string|int to bool|string|int where:
- false => same as null or not using the argument: uses 0-based keys
(as RFC currently does)
- true => uses keys from $input (suggested addition)
- int|string => uses sub-array's $indexKey'th value as key (or 0-based
for missing value, as RFC currently does)

Thoughts?

Stas Malyshev

13 years ago

Hi!

> I can submit a new pull request against the master branch, if that's
> acceptable. This is intended for 5.5.

The patch should be against 5.5, I think. 5.5 is in alpha, so adding an
isolated function to it is no problem (we're still considering adding a
major language feature to it, so function is definitely less invasive).
5.4 backport is possible - I'll look into it and if there's no potential
for problem we can have it. 5.3 is not an option on this stage, I think.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Ben Ramsey

13 years ago

On 1/12/13 10:13 AM, Peter Cowburn wrote:

> 1. Why is this branch based on 5.3, rather than 5.4 or 5.5? Do you
> want this to be part of 5.3? The RFC (in particular the vote question)
> does not make it clear where/when you want this to be added.

I mentioned this in another response on this thread. I was just
following instructions from the wiki, but I can issue another pull
request against master or some other branch.

This is intended for 5.5.

> 2. The $columnKey argument "may be the 0-indexed number of the column
> you wish to retrieve, or it may be the string key name for an
> associative array."
>
> When the nested arrays use numeric indices and the function is called
> with a number, then this argument is not "the 0-indexed number of the
> column" but rather the integer key (i.e., the $columnKey is always
> specifying the key, regardless of integer or string).  Could the
> description be updated to reflect that, if it is indeed the desired

I've updated the RFC on the wiki to include your suggestions.

> behaviour?  Also, when the nested arrays are non-0-indexed should we
> be able to somehow specify the column (rather than the key)? I have no
> answer of my own for that last question!

I'm not quite sure what you're asking here. Do you mean specifying
something like the numeric column position, rather than the string key?

>
> 3. It is not documented what happens when the $columnKey and/or
> $indexKey are not present in the nested array, could this be added?
> The current implementation appears to not include an item in the
> resulting array if $columnKey is not present. If $columnKey is present
> but $indexKey is not, a 0-based index is used in the current
> implementation.

I've added Example #4 to illustrate this.

> 4. An example of what happens when the resulting array has overlapping
> keys would not go amiss (though the behaviour is obvious).

I've added Example #5 for this.

> 5. Regarding the alias, so long as we clearly mention the word "pluck"
> (or "array_pluck") on the documentation page, folks coming from other
> languages should be able to find our implementation.  I'm not sure we
> really need it as an actual alias, but have no strong opinion one way
> or the other.

My opinion on this isn't strong, either. I've already given my rationale
in another post to this thread, but if most people want the alias
removed, I'm okay with that.

Lars Strojny

13 years ago

Hi Ben,

Am 12.01.2013 um 01:17 schrieb Ben Ramsey <ramsey@php.net>:

> I've opened voting for the array_column() function RFC.
>
> You can vote at https://wiki.php.net/rfc/array_column#voting

I voted yes, but I prefer to call it just array_pluck (no aliases). It’s what underscore.js calls it and my own pet project functional-php calls it Functional\pluck() as well. What do you think?

cu,
Lars

Adam Jon Richardson

13 years ago

On Fri, Jan 11, 2013 at 7:17 PM, Ben Ramsey <ramsey@php.net> wrote:

> I've opened voting for the array_column() function RFC.
>
> You can vote at https://wiki.php.net/rfc/array_column#voting

No voting member, here, but I'd just like to say that I like the
function, but I hope the actual implementation will only provide one
name (i.e., no aliases.) Use of an alias is nice when one regrets an
original name choice and then renames a function to better fit the
schema and context that has evolved around the function.

In this case, the function is coming in new, so please just call it array_pluck.

Adam

Adam Harvey

13 years ago

On 12 January 2013 08:17, Ben Ramsey <ramsey@php.net> wrote:

> I've opened voting for the array_column() function RFC.
>
> You can vote at https://wiki.php.net/rfc/array_column#voting

To be clear, I've voted -1 solely due to the function alias: if this
were reproposed with either name (I don't have a strong preference)
and no alias, I would be happy to switch to a +1 vote.

Adam

Ben Ramsey

13 years ago

On 1/11/13 6:17 PM, Ben Ramsey wrote:

> I've opened voting for the array_column() function RFC.
>
> You can vote at https://wiki.php.net/rfc/array_column#voting

I have updated the pull request by removing the array_pluck() alias. I
favor the array_column() alias, as it is more in keeping with other
function names like array_keys() and array_values(), which do not have
verbs in them.

If the RFC is accepted, I will submit a new pull request against the 5.5
branch and close the current pull request against the 5.3 branch. If I
should do that now, please let me know, and I'll go ahead and take care
of it.

Thanks,
Ben

Scott MacVicar

13 years ago

On 14 Jan 2013, at 11:37, Ben Ramsey <ramsey@php.net> wrote:

> On 1/11/13 6:17 PM, Ben Ramsey wrote:
>> I've opened voting for the array_column() function RFC.
>>
>> You can vote at https://wiki.php.net/rfc/array_column#voting
>
> I have updated the pull request by removing the array_pluck() alias. I favor the array_column() alias, as it is more in keeping with other function names like array_keys() and array_values(), which do not have verbs in them.
>
> If the RFC is accepted, I will submit a new pull request against the 5.5 branch and close the current pull request against the 5.3 branch. If I should do that now, please let me know, and I'll go ahead and take care of it.

I've talked about the Facebook version of this when the key bit got added, but we have 2 other methods to go with it.

mpull() which does methods
https://github.com/facebook/libphutil/blob/master/src/utils/utils.php#L110

ppull() which does properties
https://github.com/facebook/libphutil/blob/master/src/utils/utils.php#L184

Not sure if these should be added separately? The property version is good for PDO when using FETCH_CLASS.

- S

Ben Ramsey

13 years ago

On 1/14/13 11:54 AM, Scott MacVicar wrote:

> On 14 Jan 2013, at 11:37, Ben Ramsey <ramsey@php.net> wrote:
>
>> On 1/11/13 6:17 PM, Ben Ramsey wrote:
>>> I've opened voting for the array_column() function RFC.
>>>
>>> You can vote at https://wiki.php.net/rfc/array_column#voting
>>
>> I have updated the pull request by removing the array_pluck() alias. I favor the array_column() alias, as it is more in keeping with other function names like array_keys() and array_values(), which do not have verbs in them.
>>
>> If the RFC is accepted, I will submit a new pull request against the 5.5 branch and close the current pull request against the 5.3 branch. If I should do that now, please let me know, and I'll go ahead and take care of it.
>
> I've talked about the Facebook version of this when the key bit got added, but we have 2 other methods to go with it.
>
> mpull() which does methods
> https://github.com/facebook/libphutil/blob/master/src/utils/utils.php#L110
>
> ppull() which does properties
> https://github.com/facebook/libphutil/blob/master/src/utils/utils.php#L184
>
> Not sure if these should be added separately? The property version is good for PDO when using FETCH_CLASS.
>
> - S
>

I did review these, and I like them, but I think they should be added
separately, especially since they deal more with objects than arrays.

-Ben

Scott MacVicar

13 years ago

On 14 Jan 2013, at 12:57, Ben Ramsey <ramsey@php.net> wrote:

> On 1/14/13 11:54 AM, Scott MacVicar wrote:
>> On 14 Jan 2013, at 11:37, Ben Ramsey <ramsey@php.net> wrote:
>>
>>> On 1/11/13 6:17 PM, Ben Ramsey wrote:
>>>> I've opened voting for the array_column() function RFC.
>>>>
>>>> You can vote at https://wiki.php.net/rfc/array_column#voting
>>>
>>> I have updated the pull request by removing the array_pluck() alias. I favor the array_column() alias, as it is more in keeping with other function names like array_keys() and array_values(), which do not have verbs in them.
>>>
>>> If the RFC is accepted, I will submit a new pull request against the 5.5 branch and close the current pull request against the 5.3 branch. If I should do that now, please let me know, and I'll go ahead and take care of it.
>>
>> I've talked about the Facebook version of this when the key bit got added, but we have 2 other methods to go with it.
>>
>> mpull() which does methods
>> https://github.com/facebook/libphutil/blob/master/src/utils/utils.php#L110
>>
>> ppull() which does properties
>> https://github.com/facebook/libphutil/blob/master/src/utils/utils.php#L184
>>
>> Not sure if these should be added separately? The property version is good for PDO when using FETCH_CLASS.
>>
>> - S
>>
>
> I did review these, and I like them, but I think they should be added separately, especially since they deal more with objects than arrays.

As long as the work with objects that implement ArrayAccess then it should be fine?

- S

Anthony Ferrara

13 years ago

Scott,

> I did review these, and I like them, but I think they should be added
> separately, especially since they deal more with objects than arrays.
>
> As long as the work with objects that implement ArrayAccess then it should
> be fine?
>

For consistency sake, I would recommend that it does not work with objects
(even that implement ArrayAccess). Right now, the array extension (the 76+
array functions) don't accept ArrayAccess classes, so this should be no
different IMHO...

Anthony

Pierre Joye

13 years ago

hi!

Btw, really willing to have this function but I agree with other here,
the alias must go. It makes no sense to introduce a function and an
alias to it at the same time.

Maybe restart the vote and let choose function name.

Options:
1. array_column
2. array_pluck
3. none of them

Thanks for your work!

On Sat, Jan 12, 2013 at 1:17 AM, Ben Ramsey <ramsey@php.net> wrote:

> I've opened voting for the array_column() function RFC.
>
> You can vote at https://wiki.php.net/rfc/array_column#voting
>
> Regards,
> Ben
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Ben Ramsey

13 years ago

On 1/14/13 3:49 PM, Pierre Joye wrote:

> hi!
>
> Btw, really willing to have this function but I agree with other here,
> the alias must go. It makes no sense to introduce a function and an
> alias to it at the same time.
>
> Maybe restart the vote and let choose function name.
>
> Options:
> 1. array_column
> 2. array_pluck
> 3. none of them
>
> Thanks for your work!

I've already removed the array_pluck() alias. Unfortunately, after
removing the alias, it appears that some have changed their votes from
"yes" to "no," because they preferred the other function name.

That said, I'm not going to call for a vote on the function name at this
time. The predominant sentiment on the list was for it to have one
function name or the other, but not both, so I've updated the pull
request accordingly.

-Ben

Pierre Joye

13 years ago

On Mon, Jan 14, 2013 at 11:01 PM, Ben Ramsey <ramsey@php.net> wrote:

> I've already removed the array_pluck() alias. Unfortunately, after removing
> the alias, it appears that some have changed their votes from "yes" to "no,"
> because they preferred the other function name.
>
> That said, I'm not going to call for a vote on the function name at this
> time. The predominant sentiment on the list was for it to have one function
> name or the other, but not both, so I've updated the pull request
> accordingly.

Up to you, but I'd to suggest again to re do the vote and add the
naming option, easy, clear, open.

Cheers,

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Lars Strojny

13 years ago

Hi Ben,

Am 14.01.2013 um 23:16 schrieb Pierre Joye <pierre.php@gmail.com>:
[...]

> Up to you, but I'd to suggest again to re do the vote and add the
> naming option, easy, clear, open.

I was one of the people changing from yes to no because of the name. I like the functionality but I prefer no new array function over one with yet another strange name.

cu,
Lars

Matt Pelmear

13 years ago

On 01/14/2013 02:19 PM, Lars Strojny wrote:

> Hi Ben,
>
> Am 14.01.2013 um 23:16 schrieb Pierre Joye <pierre.php@gmail.com>:
> [...]
>> Up to you, but I'd to suggest again to re do the vote and add the
>> naming option, easy, clear, open.
> I was one of the people changing from yes to no because of the name. I like the functionality but I prefer no new array function over one with yet another strange name.
>
> cu,
> Lars

You'd rather the new method misuse the meaning of the word "pluck" over
following an established convention within it's own environment that is
meaningful?
If it is called "array_pluck" it should remove the data in question from
the original array. (I'm not saying that is a desirable feature here,
I'm just saying that makes more sense based on the meaning of the name
you seem to prefer.)
If there's a problem with the array functions not being verbs (which,
personally, I don't think is a huge issue as long as it is consistent),
that should be addressed for the array functions as an entire set-- not
for one particular one.


Re: the vote:
There is no point in redoing the vote at this point. If the vote does
not pass as it is, that means either the community doesn't support the
new feature or they don't support the proposed function name.
It's obvious, based on the current vote results, that the community does
support the feature, so it is simply a matter of issuing a second vote
if this one fails.


-Matt

Herman Radtke

13 years ago

> If it is called "array_pluck" it should remove the data in question from the
> original array. (I'm not saying that is a desirable feature here, I'm just
> saying that makes more sense based on the meaning of the name you seem to
> prefer.)

Why do you think pluck is destructive? In most examples I have come
across it merely 'plucks' a certain key from a dictionary and does so
in a way that does not modify the original dictionary.

Sources:
Underscore.js - http://documentcloud.github.com/underscore/#pluck
Rails - http://apidock.com/rails/ActiveRecord/Calculations/pluck
Python example: http://stackoverflow.com/questions/9816545/pluck-in-python

--
Herman Radtke
@hermanradtke | http://hermanradtke.com

Matt Pelmear

13 years ago

On 01/14/2013 10:12 PM, Herman Radtke wrote:

>> If it is called "array_pluck" it should remove the data in question from the
>> original array. (I'm not saying that is a desirable feature here, I'm just
>> saying that makes more sense based on the meaning of the name you seem to
>> prefer.)
> Why do you think pluck is destructive? In most examples I have come
> across it merely 'plucks' a certain key from a dictionary and does so
> in a way that does not modify the original dictionary.
>
> Sources:
> Underscore.js - http://documentcloud.github.com/underscore/#pluck
> Rails - http://apidock.com/rails/ActiveRecord/Calculations/pluck
> Python example: http://stackoverflow.com/questions/9816545/pluck-in-python
>

Sources:
1. google:    "define: pluck"
"Take hold of (something) and quickly *remove* it from it's place"
2. http://www.merriam-webster.com/dictionary/pluck
"to pull or *pick* off or *out*"
3. http://www.thefreedictionary.com/pluck
"To *remove* or detach ..."

Emphasis added. The connotation of the word is that something is
*removed* from it's original place.

Just because other languages/frameworks have made a poor naming choices
doesn't mean PHP should too. In this case, there is already an
alternatively proposed method name which is more obvious way to name the
method that fits within the established PHP conventions.


I'm picky about naming things. :-)

-Matt

Gustavo Lopes

13 years ago

On Mon, 14 Jan 2013 23:16:52 +0100, Pierre Joye <pierre.php@gmail.com>
wrote:

> On Mon, Jan 14, 2013 at 11:01 PM, Ben Ramsey <ramsey@php.net> wrote:
>
>> I've already removed the array_pluck() alias. Unfortunately, after
>> removing the alias, it appears that some have changed their votes from
>> "yes" to "no," because they preferred the other function name.
>>
>> That said, I'm not going to call for a vote on the function name at this
>> time. The predominant sentiment on the list was for it to have one
>> function name or the other, but not both, so I've updated the pull
>> request
>> accordingly.
>
> Up to you, but I'd to suggest again to re do the vote and add the
> naming option, easy, clear, open.
>

I don't think either easier or clear. Then all sort of questions come up
if none of the three options has an absolute majority. And if you open two
separate and concurrent votes you're taking from people the power to
condition the vote on a specific choice of name.

Personally, I don't care about the name as long as only one is chosen (no
alias).

--
Gustavo Lopes

Lars Strojny

13 years ago

It’s quite simple:

- Do you want to include the functionality: yes/no
- If you want to include it, which name should it have: array_column/array_pluck

Am 14.01.2013 um 23:23 schrieb Gustavo Lopes <glopes@nebm.ist.utl.pt>:

Gustavo Lopes

13 years ago

On Mon, 14 Jan 2013 23:43:31 +0100, Lars Strojny <lars@strojny.net> wrote:

>  - Do you want to include the functionality: yes/no
>  - If you want to include it, which name should it have:
> array_column/array_pluck

? You said earlier:

> I was one of the people changing from yes to no because
> of the name. I like the functionality but I prefer no
> new array function over one with yet another strange name.

You realize you cannot express this choice under the setup you proposed
right? That is why processes that include a general vote followed by
amendments or other detail decisions (like you propose) usually include a
final global vote at the end.

--
Gustavo Lopes

Peter Cowburn

13 years ago

Hi Ben,

On 12 January 2013 00:17, Ben Ramsey <ramsey@php.net> wrote:

> I've opened voting for the array_column() function RFC.
>
> You can vote at https://wiki.php.net/rfc/array_column#voting
>
> Regards,
> Ben
>

The vote has been open for almost three weeks and discussion tailed
off after only a few days here. What are your thoughts or plans on
moving forward with this, or at least coming to a conclusion: given
the current state of play (over 80% voted yay thus far) and the
release timeline (moving along with the 5.5.0 alphas), not that
there's any reason to necessarily rush anywhere.

I know the list has been a bit crazy recently so this might have been
cast out of the limelight a little, perhaps.

Cheers,

Peter

Pierre du Plessis

13 years ago

> On 12 January 2013 00:17, Ben Ramsey <ramsey@php.net> wrote:
> > I've opened voting for the array_column() function RFC.
> >
> > You can vote at https://wiki.php.net/rfc/array_column#voting
> >
> > Regards,
> > Ben
> >
>
> The vote has been open for almost three weeks and discussion tailed
> off after only a few days here. What are your thoughts or plans on
> moving forward with this, or at least coming to a conclusion: given
> the current state of play (over 80% voted yay thus far) and the
> release timeline (moving along with the 5.5.0 alphas), not that
> there's any reason to necessarily rush anywhere.
>
> I know the list has been a bit crazy recently so this might have been
> cast out of the limelight a little, perhaps.
>
> Cheers,
>
> Peter
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Is there any plans to get this into 5.5?
Voting has a majority yes, and the 5.5 beta feature-freeze is almost upon
us.

Ben Ramsey

13 years ago

Sorry. I got sick for a few weeks, and this fell to the bottom of my
priorities list.

I'm not sure what the next steps are. This was approved by a majority vote.
What do I need to do now to get it into 5.5?

Thanks,
Ben



On Wed, Feb 27, 2013 at 6:51 AM, Pierre du Plessis
<pierre@pcservice.co.za>wrote:

Pierre Joye

13 years ago

On Thu, Feb 28, 2013 at 2:56 AM, Ben Ramsey <ramsey@php.net> wrote:

> Sorry. I got sick for a few weeks, and this fell to the bottom of my
> priorities list.
>
> I'm not sure what the next steps are. This was approved by a majority vote.
> What do I need to do now to get it into 5.5?

Please kill that alias. It is pointless to introduce a new function
with an alias for it.

Cheers,

--
Pierre

@pierrejoye

Ben Ramsey

13 years ago

> Please kill that alias. It is pointless to introduce a new function
> with an alias for it.
>
>

I killed the alias in this commit:
https://github.com/ramsey/php-src/commit/3439a098a0b646ff05d4da9748996214cac39d12

-Ben

Peter Cowburn

13 years ago

Hi Ben,

On 28 February 2013 01:56, Ben Ramsey <ramsey@php.net> wrote:

> Sorry. I got sick for a few weeks, and this fell to the bottom of my
> priorities list.
>
> I'm not sure what the next steps are. This was approved by a majority vote.
> What do I need to do now to get it into 5.5?
>
> Thanks,
> Ben
>

The next step is to get someone (anyone with php-src karma) to merge
your pull request. Assuming you're all done and happy with the pull
request?

The RMs (cc'd) are looking to tag the beta tomorrow and I for one
would like to get this little function in there.

Cheers,
Peter