Re: Any interest in a list type?
| From: | Larry Garfield | Date: | Wed, 22 Apr 2020 22:47:08 +0000 |
| Subject: | Re: Any interest in a list type? | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-109792@lists.php.net to get a copy of this message | ||
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