On Wed, Apr 22, 2020, at 3:44 PM, Matthew Brown wrote: > > map/filter/reduce need to be recast to work on any iterable, which would > then include lists > > Lists would only make sense if we're also rethinking how collections work > generally > > I disagree – I think the most successful PHP language additions have been > those that allow PHP developers to improve their code without having to > think too hard – for example, property, return and param types can be added > to existing code without changing its behaviour at runtime, as long as the > added types align with actual behaviour. > > If list types work in a wholly different fashion to arrays, they won't be a > drop-in-replacement, they won't feel familiar to the average PHP developer, > and I imagine few people would update existing code to use them, because > it'd be too risky.
1) Please don't top-post. 2) I don't mean "make them as unlike arrays as possible". I mean "think through the implications of having a *third* type of iterable; what other functions would be affected? Should we reconsider how map/filter/reduce work generally instead of just throwing a bunch more random functions at it? What are the knock-on effects? Should we also be adding a dedicated dictionary type as well? Why or why not?" This is the *design* process for a language, and it's important. "Let's just throw a numeric-only list type into the pool and see what happens" is a very bad idea. 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. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
