On Mon, Jul 1, 2024, at 4:48 AM, Michał Marcin Brzuchalski wrote: > pon., 1 lip 2024 o 03:01 Larry Garfield <la...@garfieldtech.com> napisał(a):
>> Contextual point: Nearly every other major language at this point that has a >> meaningful standard library has gone with a three-separate-object approach >> (Seq, Set, Dict, called various things). At least Python, Javascript, Rust, >> Kotlin, and Swift, in my research. (Go doesn't, but Go avoids having >> features by design.) And AFAIK *every* language except PHP and Lua >> separates sequences from dictionaries. Typed arrays will not full resolve >> the seq vs dict problem, which is arguably PHP's original sin. And there's >> a lot of weird issues to resolve around what the syntax could even be, since >> PHP has untyped variables. >> >> The custom collection syntax Derick has been working on is a second-best >> alternative to generics, essentially. It is less ergonomic, no question, >> but can also be implemented without generics, and so is about 5x easier to >> do. If we could get native generics, then I think everyone involved agrees >> building collections off of that -- in essentially the same way as every >> language I mentioned above --- would be preferable to a custom one-off >> syntax. >> >> --Larry Garfield > > Considering other languages it is worth mentioning that Java and C# > have generics AND typed arrays that act as a typed list/seq so sure it > doesn't solve all problems otherwise these languages wouldn't have both > of them. I believe in those languages Array came first, and then the collections were added later when they determined that Array was insufficient and too low-level. (I'm not an expert on the history of either language, but that's my understanding from reading their documentation.) Using the collections is the preferred approach now for most applications. > From my personal experience, a typed list/seq solves most cases where I > need the elements of an array to be strictly instances of a specific > type. > What I see typed list/seq like `string[]` has more ergonomics, it can > be used to interact between libraries and application code without > creating intermediate objects, while collection<Dict> proposal always > requires declaring type - this simply multiplies the number of declared > types and create more coupling where it is not needed! Also, most cases > I work with are just fine with using just foreach or array_ family > functions. Yes, the need to create the monomorphized object yourself is a downside of the dedicated collections syntax. No question. The trade-off is that it's vastly easier to implement than either full generics or typed arrays. We haven't fully developed it yet as there's still experimentation going on (by people with far more engine knowledge than me) to see if we can have our cake and eat it too. > This doesn't have to collide with generics in any way, as mentioned > before in the thread these features may exist simultaneously, typed > list/seq can translate in the future to a generic type. > I believe it'd make people's lives easier if we could have this in > place soon. > Don't you agree? > > Cheers, > Michał Marcin Brzuchalski 1. I think you are vastly under-estimating the level of effort for making typed arrays, and making them performant. Arnaud has been exploring that, and it's far from trivial. "Have this in place soon" hand-waves over an awful lot of complexity. 2. You're correct that typed arrays and generics could coexist in the language, if both could be implemented. But that is also a lot of work, with overlapping problem spaces. 3. The core failing of typed arrays is that they still don't guarantee a sequence; everything is still a string|int key dictionary with no support for object keys, and PHP's screwy array-specific type casting. Frankly, people who don't see the challenges here have not tried to write array-handling libraries. :-) (Crell/fp taught me all kinds of things about how broken arrays are, due to their fundamental unpredictability.) --Larry Garfield
