> Is it an effective subtype of array? I was thinking it should be (with the auto-conversion mentioned above), but I can see a compelling case to not have the auto-conversion when manipulating – while it would bloat the stdlib a little (we'd need a whole bunch of list_* functions) the separation would simplify things a lot (e.g. list_filter would return a list with sequential keys, whereas array_filter returns an array with possibly non-sequential keys)
And then you could cast between the two like "(list) $some_array" (which would preserve order but remove keys) and "(array) $some_list" as necessary. There could even be some automatic list <-> array casting when calling functions not in strict_types mode. > Should they pass like arrays or like objects Definitely like arrays – I want them to be a drop-in-replacement for people who currently use arrays in places lists are more appropriate. > Should they be mutable or immutable Definitely mutable, like arrays are > Are they iterable Yes, the keys are sequential integers > Does it make sense to add them without type enforcement via generics Absolutely – this shouldn't be tied to generics landing (which I'd imagine is a PHP 9 feature at this point, whereas this could be a PHP 8.x feature). > can they be mapped/filtered/reduced Absolutely – I think we'd have list_map, list_filter, list_reduce functions to provide that functionality. On Wed, 22 Apr 2020 at 13:28, Larry Garfield <la...@garfieldtech.com> wrote: > On Tue, Apr 21, 2020, at 2:00 PM, Matthew Brown wrote: > > Before I create an RFC or attempt a reference implementation, is there > any > > interest in adding (and then obviously supporting in perpetuity) a list > > type? > > > > The first line of PHP's documentation for "array" states: "An array in > PHP > > is actually an ordered map". There are some optimisations that make > arrays > > with ordered integer keys faster, but I'd be interested in a separate > type > > dedicated to *sequential* integer keys. Such a type would presumably > > consume a little less memory. > > > > Why "list" and not "vec" or similar? "list" is also a reserved word – I'm > > imagining that you'd construct a list like > > > > $l = list["a", "b", "c"]; > > > > I imagine such a "list" type would be a subtype of "array" – everywhere > > that array was accepted, a list would be also, and it would have the same > > copy-on-write behaviour. > > > > If people are interested in having that type, there's a question of what > to > > do with > > > > $some_list["a"] = 5; > > > > Would you convert the $some_list to an array, or throw an exception? > > Converting to an array would seem the more PHP-like thing to do. > > > > Similarly, the behaviour of > > > > $some_list[$key_out_of_current_range] = 5 > > > > would be a matter of debate too – would that turn $some_list into an > array, > > or would it fill up any preceding entries in the array with null? > > > > What other questions are there? Is a "list" type even a good fit for PHP, > > given most of its users seem pretty content with the current > > swiss-army-knife array type? > > Most users don't realize that PHP's arrays-not-really-arrays have caused > millions of dollars in security breaches in the past. :-) They're > dangerous and to be avoided whenever possible. > > I'm very open to a list/sequence type, but as others have noted there's a > whole crapload of details to sort out to make it viable. In particular: > > * Is it an effective subclass of array? IMO, no. It should have > absolutely no auto-conversion to/from an array whatsoever of any kind, > period. Keep them as separate as possible. > > * Should it even have random-access indexes? Honestly I'd say no; Just > support adding, removing, and iteration and generate the indexes on the fly > when iterating if necessary. > > * Should they pass like arrays or like objects? Many questions here. > > * Should they be mutable or immutable? I could argue for either one > effectively, I think, though I'd honestly favor immutable. > > * Are they iterable? Presumably, but does that have any weird > implications for iterables that implicitly assume there are keys? How's > that work? > > * Does it make sense to add them without type enforcement via generics? > Lists + Generics would be lovely, but as we've seen Generics are Hard(tm) > and Not Imminent(tm). But would adding them now make a generic version > harder in the future? (I've no idea.) > > * Besides add/remove/iterate, what other baked-in functionality should > they have? Eg, can they be mapped/filtered/reduced? It would really suck > to revisit lists and not fix that disconnect in the API. (Insert me > talking about comprehensions and stuff here.) Ideally this would happen as > part of a larger review of how collections work at various levels, which > are currently highly clunky. > > Those are all solvable problems (and I've likely forgotten several), but > they would have to be thought through extensively before an implementation > could be viable. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
