Gustavo Lopes | 28 May 15:34 2012
Picon

[PHP-DEV] [VOTE] array_part()

I've opened the array_part() vote:

https://wiki.php.net/rfc/array_part#vote

The vote asks whether the branch at  
https://github.com/cataphract/php-src/tree/array_part should be merged.  
This implementation has been tested and has 100% code coverage on the  
reachable code.

-- 
Gustavo Lopes

--

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

Stas Malyshev | 29 May 02:28 2012

Re: [PHP-DEV] [VOTE] array_part()

Hi!

> I've opened the array_part() vote:
> 
> https://wiki.php.net/rfc/array_part#vote
> 
> The vote asks whether the branch at  
> https://github.com/cataphract/php-src/tree/array_part should be merged.  
> This implementation has been tested and has 100% code coverage on the  
> reachable code.

This looks very complicated. It might be that some use cases require
this level of complexity, but I can't remember a case where I would need
it. That alone does not disqualify the proposal, but I personally very
much like having something like array_column() rather than whole array
slicing engine with it's own declarative language inside. The engine
might be fine, but I imagine many users would want just something like
array_column() - so at least it'd be nice to have both.
-- 
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

Gustavo Lopes | 29 May 10:05 2012
Picon

Re: [PHP-DEV] [VOTE] array_part()

On Tue, 29 May 2012 02:28:05 +0200, Stas Malyshev <smalyshev <at> sugarcrm.com>  
wrote:

> This looks very complicated. It might be that some use cases require
> this level of complexity, but I can't remember a case where I would need
> it. That alone does not disqualify the proposal, but I personally very
> much like having something like array_column() rather than whole array
> slicing engine with it's own declarative language inside. The engine
> might be fine, but I imagine many users would want just something like
> array_column() - so at least it'd be nice to have both.

1)
Independently for whether we want array_column this function does things  
that no other function built-in currently does and some that no userland  
function can even do:

* Extract slices without side effects (array_slice() has side effects).
* Extract slices based on keys on time proportional to the size of the  
slice and not to the size of the array.
* Pick an arbitrary number of elements from an array in any permutation  
and traversing the array, in worst case -- if we request an element in the  
middle --, only once.

2)
A lot of people seem to think this is too complicated. I think that  
objection comes from several places:

* People focusing on the most complex usages of the function. The test  
cases have to cover complex usages in order to exercise the implementation  
correctly, but that doesn't mean the majority of use cases will be that  
(Continue reading)


Gmane