Re: Re: RFC: CachedIterable (rewindable, allows any key&repeating keys)
| From: | Alexandru Pătrănescu | Date: | Thu, 10 Jun 2021 05:05:12 +0000 |
| Subject: | Re: Re: RFC: CachedIterable (rewindable, allows any key&repeating keys) | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-114805@lists.php.net to get a copy of this message | ||
On Wed, Jun 9, 2021 at 3:22 AM tyson andre <tysonandre775@hotmail.com>
wrote:
> Hi internals,
>
> > I've created a new RFC
> > https://wiki.php.net/rfc/cachediterable adding
> CachedIterable,
> > which eagerly evaluates any iterable and contains an immutable copy of
> the keys and values of the iterable it was constructed from
> >
> A heads up - I will probably start voting on
> https://wiki.php.net/rfc/cachediterable this weekend after
> https://wiki.php.net/rfc/cachediterable_straw_poll is finished.
>
> Any other feedback on CachedIterable?
>
> Thanks,
> Tyson
>
>
Hi Tyson,
Thanks for explaining 4 months ago about my concern.
I think I understand the main real impact of an eager iterable cache vs a
lazy iterable cache from a functional point of view:
- exceptions are thrown during construction vs during the first iteration
- predictable performance also on the first iteration.
How did you gather the information that eager implementation is more
valuable than lazy one? I'm mostly curious also how to assess this as
technically to me it also looks the other way around. Maybe mention that in
the RFC.
I was even thinking that CachedIterable should be lazy and an
EagerCachedIterable would be built upon that with more methods. Or have it
in the same class with a constructor parameter.
Also, being able to have a perfect userland implementation, not very
complex, even considering the lower performance, is not that good for
positive voting from what I remember from history...
Regards,
Alex