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
