Re: [PHP-DEV] [VOTE] array_column() function

[Peter Cowburn]

Hi Ben,

On 28 February 2013 01:56, Ben Ramsey  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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Ben Ramsey]

> 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 

Re: [PHP-DEV] [VOTE] array_column() function

[Pierre Joye]

On Thu, Feb 28, 2013 at 2:56 AM, Ben Ramsey  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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Ben Ramsey]

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

>
> On 12 January 2013 00:17, 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
>> >
>>
>> 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.
>

Re: [PHP-DEV] [VOTE] array_column() function

[Pierre du Plessis]

> On 12 January 2013 00:17, 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
> >
>
> 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.

Re: [PHP-DEV] [VOTE] array_column() function

[Peter Cowburn]

Hi Ben,

On 12 January 2013 00:17, 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
>

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

Re: [PHP-DEV] [VOTE] array_column() function

[Matt Pelmear]

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



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Herman Radtke]

> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Matt Pelmear]

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

Hi Ben,

Am 14.01.2013 um 23:16 schrieb Pierre Joye :
[...]

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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Gustavo Lopes]

On Mon, 14 Jan 2013 23:43:31 +0100, Lars Strojny  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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Lars Strojny]

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 :

> On Mon, 14 Jan 2013 23:16:52 +0100, Pierre Joye  wrote:
> 
>> On Mon, Jan 14, 2013 at 11:01 PM, Ben Ramsey  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
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Gustavo Lopes]

On Mon, 14 Jan 2013 23:16:52 +0100, Pierre Joye   
wrote:



On Mon, Jan 14, 2013 at 11:01 PM, Ben Ramsey  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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Lars Strojny]

Hi Ben,

Am 14.01.2013 um 23:16 schrieb Pierre Joye :
[...]
> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Pierre Joye]

On Mon, Jan 14, 2013 at 11:01 PM, Ben Ramsey  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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Ben Ramsey]

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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Pierre Joye]

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Lars Strojny]

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 :

> On Sat, Jan 12, 2013 at 12:04 AM, Levi Morrison  
> 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
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Herman Radtke]

On Sat, Jan 12, 2013 at 12:04 AM, Levi Morrison  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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Adam Harvey]

On 12 January 2013 08:17, 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

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Galen Wright-Watson]

On Sat, Jan 12, 2013 at 7: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().
>

As an alternative to an alias, what about a manual page for whichever name
isn't used that redirects or (like 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?

Re: [PHP-DEV] [VOTE] array_column() function

[Stas Malyshev]

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Adam Jon Richardson]

On Fri, Jan 11, 2013 at 7: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

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Stas Malyshev]

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Stas Malyshev]

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Peter Cowburn]

On 12 January 2013 16:41, Ben Ramsey  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?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Matt Pelmear]

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Lars Strojny]

Hi Ben,

Am 12.01.2013 um 01:17 schrieb Ben Ramsey :

> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Ben Ramsey]

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.



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





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Ben Ramsey]

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Nikita Popov]

On Sat, Jan 12, 2013 at 4:54 PM, Derick Rethans  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

Re: [PHP-DEV] [VOTE] array_column() function

[Levi Morrison]

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Peter Cowburn]

On 12 January 2013 00:17, 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 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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Thomas Hruska]

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/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Clint Priest]

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

Re: [PHP-DEV] [VOTE] array_column() function

[Derick Rethans]

On Sat, 12 Jan 2013, Nikita Popov wrote:

> On Sat, Jan 12, 2013 at 6:57 AM, Stas Malyshev 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Ben Ramsey]

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Ben Ramsey]

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.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Derick Rethans]

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Derick Rethans]

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Peter Cowburn]

On 12 January 2013 00:17, 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
>

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?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Nikita Popov]

On Sat, Jan 12, 2013 at 6:57 AM, Stas Malyshev 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

Re: [PHP-DEV] [VOTE] array_column() function

[Levi Morrison]

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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Kris Craig]

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

Re: [PHP-DEV] [VOTE] array_column() function

[Anthony Ferrara]

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

Re: [PHP-DEV] [VOTE] array_column() function

[Stas Malyshev]

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Arpad Ray]

On Sat, Jan 12, 2013 at 12:21 AM, Nikita Popov  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

Re: [PHP-DEV] [VOTE] array_column() function

[Nikita Popov]

On Sat, Jan 12, 2013 at 1:36 AM, Matt Pelmear  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

Re: [PHP-DEV] [VOTE] array_column() function

[Matt Pelmear]

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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] array_column() function

[Nikita Popov]

On Sat, Jan 12, 2013 at 1:17 AM, 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
>

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