Any interest in a list type?

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

--

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