I've opened voting for the array_column() function RFC.
You can vote at https://wiki.php.net/rfc/array_column#voting
Regards,
Ben
I've opened voting for the
array_column()function RFC.You can vote at https://wiki.php.net/rfc/**array_column#votinghttps://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
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
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
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:
- 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...
- 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...
- 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
On Fri, Jan 11, 2013 at 10:53 PM, Anthony Ferrara ircmaxell@gmail.comwrote:
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.phpIMHO, a new function should be added in one of three cases:
- 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...
- 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...
- 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
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.
The real problem here (in my opinion) is that
array_filterdoes 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
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:
The real problem here (in my opinion) is that
array_filterdoes 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
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.
On Sat, Jan 12, 2013 at 6:57 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
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
On Sat, Jan 12, 2013 at 6:57 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
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
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
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
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
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
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
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?
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.
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
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:
-
Userland PHP developers instantly recognize
array_column(). It's
self-descriptive, and they know what it means. -
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 forarray_column().
-Ben
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
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 forarray_column()and
arguments for array_pluck(), so I added an alias.Here's why I think the alias should be considered:
Userland PHP developers instantly recognize
array_column(). It's
self-descriptive, and they know what it means.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 forarray_column().-Ben
--
-Clint
Hi,
- 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 forarray_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
Hi!
- 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 forarray_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
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 forarray_column()and arguments for
array_pluck(), so I added an alias.Here's why I think the alias should be considered:
Userland PHP developers instantly recognize
array_column(). It's
self-descriptive, and they know what it means.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 forarray_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?
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.
-
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. -
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!
-
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. -
An example of what happens when the resulting array has overlapping
keys would not go amiss (though the behaviour is obvious). -
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.
- 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.
- 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
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?
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
- 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.
- 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?
- 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.
- 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.
- 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.
Overall, I'm liking this simple addition to the array library.
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
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
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
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
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 likearray_keys()andarray_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'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 likearray_keys()andarray_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#L110ppull() which does properties
https://github.com/facebook/libphutil/blob/master/src/utils/utils.php#L184Not 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
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 likearray_keys()andarray_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#L110ppull() which does properties
https://github.com/facebook/libphutil/blob/master/src/utils/utils.php#L184Not 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
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
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:
- array_column
- array_pluck
- none of them
Thanks for your work!
I've opened voting for the
array_column()function RFC.You can vote at https://wiki.php.net/rfc/array_column#voting
Regards,
Ben--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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:
- array_column
- array_pluck
- 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
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
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
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
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
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:
- google: "define: pluck"
"Take hold of (something) and quickly remove it from it's place" - http://www.merriam-webster.com/dictionary/pluck
"to pull or pick off or out" - 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
On Mon, 14 Jan 2013 23:16:52 +0100, Pierre Joye pierre.php@gmail.com
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
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:
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
- 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
Hi Ben,
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
I've opened voting for the
array_column()function RFC.You can vote at https://wiki.php.net/rfc/array_column#voting
Regards,
BenThe 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
--
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.
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.zawrote:
I've opened voting for the
array_column()function RFC.You can vote at https://wiki.php.net/rfc/array_column#voting
Regards,
BenThe 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
--
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.
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
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
Hi Ben,
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