> On 23 Apr 2020, at 23:05, Larry Garfield <la...@garfieldtech.com> wrote:
>
> On Thu, Apr 23, 2020, at 12:02 AM, Matthew Brown wrote:
>>> This is the *design* process for a language, and it's important...
>> Stepping back to reconsider how collections work generally, and how we can
>> improve them in a graceful way that leads to a clean end-state, would be
>> very valuable.
>> Though you have much more experience with internals than I do, I think that
>> building a consensus around a bold new vision for PHP collections would be
>> a near-Sisyphean task.
>
> Disclosure: I've been around the list for over a decade and talked a lot, but
> the recent pipe RFC is my first core patch. I'm still one of the little
> people around here. :-) Though I have successfully engaged in Sisyphean
> tasks before. (GoPHP5, Drupal 8, FIG, etc.)
>
>> Adding a list/vector type would be a much smaller, more easily definable
>> task – it was one of the first new types that Hack added, and by all
>> accounts they're pretty happy with that decision.
>
> I think we may be talking past each other. I don't mean "rewrite all the
> things." Just taking the time to think through "if we have a list type,
> generators, and array/dicts, what should all of the ancillary bits around
> them be to make them as smooth as possible?" Viz, how do we NOT have
> array_map, list_map, and generator_map as 3 separate functions, because that
> would be awful. Are list generators and array/dict generators different
> things or the same thing, or...? Would comprehensions make sense as part of
> such a plan? (IMO yes.) But then, do comprehensions produce lists or dicts
> or...?
>
> That's the sort of knock-on effects that should be thought through before we
> commit code, because in the long run it would reduce the amount of code to
> commit (and the amount of WTF for users).
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
Hi Larry,
I may be missing something here, but couldn’t the three types be handled by a
set of `iterator_{map,filter,...}` functions?
Array_map probably has to stay as is because it’s signature and method of
operation is (IMO) not something that should be carried over, but array filter
could possibly just become an alias to iterator_filter?
Cheers
Stephen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
