Req #76865 [Com]: RFC: make `array_*` functions handling `iterable`, not only `array`
| From: | scif-1986 at ya dot ru | Date: | Thu, 28 Feb 2019 23:45:16 +0000 |
| Subject: | Req #76865 [Com]: RFC: make `array_*` functions handling `iterable`, not only `array` | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-219778@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=76865&edit=1
ID: 76865
Comment by: scif-1986 at ya dot ru
Reported by: scif-1986 at ya dot ru
Summary: RFC: make
array_* functions handling iterable,
not only array
Status: Open
Type: Feature/Change Request
Package: Arrays related
PHP Version: Next Minor Version
Block user comment: N
Private report: N
New Comment:
Hi guys, is there any update on this proposal? It sounds reasonable, doesn't it?
Thanks!
Previous Comments:
------------------------------------------------------------------------
[2018-11-19 14:53:25] zhujinxuan at gmail dot com
Personally, I think it is better to provide a namespace like STD and then, in that
namespace, implement functions polyfilled for array. iterator and all possible foldable interfaces.
For that library, we can use an PHP implementation as the first release, and then make it to C and
merge it to main PHP branch when the API seems stable, For a long time, we are in a lack of standard
library with consistency.
------------------------------------------------------------------------
[2018-09-12 04:18:17] requinix@php.net
Some comments that will likely arise:
* The single-pass functions (eg, map, column, chunk, combine) could benefit from this
* The more complicated functions (eg, diff) would need iterator_to_array
* iterator_apply would presumably be made an alias of array_map
* These functions can be called multiple times on arrays but not necessarily so on iterators
* What happens when the iterator is exhausted?
That last point is the main reason why this question tends to be resolved one way: using
iterator_to_array is a benefit, not a hindrance, as it reminds the developer that the source was not
a simple array that can be easily reused.
------------------------------------------------------------------------
[2018-09-12 01:29:11] scif-1986 at ya dot ru
Actually, these functions will still return an array as a result :) Also, I can't find any
suitable name for such functions. iterable_diff()? Looks ugly. And array will still be
the valid input.
------------------------------------------------------------------------
[2018-09-12 01:20:21] carusogabriel@php.net
This is something I'd love to see implemented, but, I don't know if we should change the
array_* functions. By they starting with "array_", we presume that one of the
arguments is gonna be an array, not an iterable.
I can try to create POC within the next weeks and open for discussion on internals@ :)
------------------------------------------------------------------------
[2018-09-12 01:04:19] scif-1986 at ya dot ru
Description:
------------
The iterable pseudo-type has been introduced for a while and is very useful. While
array_*() core functions are still doesn't support iterable as
argument and works with array only. Obviously, I'm talking about
array_map()/array_column()/array_diff(),array_chunk()/array_combine()⦠which
don't change an argument by pointer.
Sorry, don't know C, so it's just an idea :)
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=76865&edit=1