Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113136
To: PHP internals <internals@lists.php.net>
Thread-Topic: RFC: CachedIterable (rewindable, allows any key&repeating keys)
Thread-Index: AQHXACLkMdQqZoaVtUy2vSZWXRDmOQ==
Date: Thu, 11 Feb 2021 03:47:03 +0000
Message-ID:
 <DM6PR07MB66182D44C3AFFAB73D6DED43F98C9@DM6PR07MB6618.namprd07.prod.outlook.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: d7f6753c-f3de-4cd7-9c80-08d8ce3fb1d1
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2021 03:47:03.3421
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM11HT046
Subject: RFC: CachedIterable (rewindable, allows any key&repeating keys)
From: tysonandre775@hotmail.com (tyson andre)

Hi internals,=0A=
=0A=
I've created a new RFC https://wiki.php.net/rfc/cachediterable adding Cache=
dIterable,=0A=
which eagerly evaluates any iterable and contains an immutable copy of the =
keys and values of the iterable it was constructed from=0A=
=0A=
This has the proposed signature:=0A=
=0A=
```=0A=
final class CachedIterable implements IteratorAggregate, Countable, JsonSer=
ializable=0A=
{=0A=
    public function __construct(iterable $iterator) {}=0A=
    public function getIterator(): InternalIterator {}=0A=
    public function count(): int {}=0A=
    // [[$key1, $value1], [$key2, $value2]]=0A=
    public static function fromPairs(array $pairs): CachedIterable {}=0A=
    // [[$key1, $value1], [$key2, $value2]]=0A=
    public function toPairs(): array{} =0A=
    public function __serialize(): array {}  // [$k1, $v1, $k2, $v2,...]=0A=
    public function __unserialize(array $data): void {}=0A=
 =0A=
    // useful for converting iterables back to arrays for further processin=
g=0A=
    public function keys(): array {}  // [$k1, $k2, ...]=0A=
    public function values(): array {}  // [$v1, $v2, ...]=0A=
    // useful to efficiently get offsets at the middle/end of a long iterab=
le=0A=
    public function keyAt(int $offset): mixed {}=0A=
    public function valueAt(int $offset): mixed {}=0A=
 =0A=
    // '[["key1","value1"],["key2","value2"]]' instead of '{...}'=0A=
    public function jsonSerialize(): array {}=0A=
    // dynamic properties are forbidden=0A=
}=0A=
```=0A=
=0A=
Currently, PHP does not provide a built-in way to store the state of an arb=
itrary iterable for reuse later=0A=
(when the iterable has arbitrary keys, or when keys might be repeated). It =
would be useful to do so for many use cases, such as:=0A=
=0A=
1. Creating a rewindable copy of a non-rewindable Traversable =0A=
2. Generating an IteratorAggregate from a class still implementing Iterator=
=0A=
3. In the future, providing internal or userland helpers such as iterable_f=
lip(iterable $input), iterable_take(iterable $input, int $limit),=0A=
    iterable_chunk(iterable $input, int $chunk_size), iterable_reverse(), e=
tc (these are not part of the RFC)=0A=
4. Providing memory-efficient random access to both keys and values of arbi=
trary key-value sequences =0A=
=0A=
Having this implemented as an internal class would also allow it to be much=
 more efficient than a userland solution=0A=
(in terms of time to create, time to iterate over the result, and total mem=
ory usage). See https://wiki.php.net/rfc/cachediterable#benchmarks=0A=
=0A=
After some consideration, this is being created as a standalone RFC, and go=
ing in the global namespace:=0A=
=0A=
- Based on early feedback on https://wiki.php.net/rfc/any_all_on_iterable#s=
traw_poll (on the namespace preferred in previous polls)=0A=
  It seems like it's way too early for me to be proposing namespaces in any=
 RFCs for PHP adding to modules that already exist, when there is no consen=
sus.=0A=
=0A=
  An earlier attempt by others on creating a policy for namespaces in gener=
al(https://wiki.php.net/rfc/php_namespace_policy#vote) also did not pass.=
=0A=
=0A=
  Having even 40% of voters opposed to introducing a given namespace (in pr=
e-existing modules)=0A=
  makes it an impractical choice when RFCs require a 2/3 majority to pass.=
=0A=
- While some may argue that a different namespace might pass,=0A=
  https://wiki.php.net/rfc/any_all_on_iterable_straw_poll_namespace#vote ha=
d a sharp dropoff in feedback after the 3rd form.=0A=
  I don't know how to interpret that - e.g. are unranked namespaces preferr=
ed even less than the options that were ranked or just not seen as affectin=
g the final result.=0A=
=0A=
Any other feedback unrelated to namespaces?=0A=
=0A=
Thanks,=0A=
- Tyson=