Re: Any interest in a list type?

> On 23 Apr 2020, at 23:05, Larry Garfield <larry@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