On Sat, 18 Sept 2021 at 12:04, Larry Garfield <la...@garfieldtech.com> wrote:
> > I am frequently on-record hating on PHP arrays, and stating that I want > something better. The problems with PHP arrays include: > > 1. They're badly performing (because they cannot be optimized) > 2. They're not type safe > 3. They're mutable > 4. They mix sequences (true arrays) with dictionaries/hashmaps, making > everything uglier > 5. People keep using them as structs, when they're not > 6. The API around them is procedural, inconsistent, and overall gross > 7. They lack a lot of native shorthand operations found in other languages > (eg, slicing) > 8. Their error handling is crap > > Any new native/stdlib alternative to arrays needs to address at least half > of those issues, preferably most/all. > Hey Larry, I believe 1. and 2. are an impossible standard for any PHP-based proposal to meet. If you want it to be (runtime) type-safe, that assumes the existence of runtime type checks which can quickly become a performance bottleneck. For 3, having explored immutability in depth with Psalm, arrays don't present any sort of challenge due to their copy-on-write behavior. There's a chunk of Psalm's codebase that makes heavy use of arrays, and it's still provably pure. 5: they're used as makeshift structs, but there's nothing preventing people using constructor property promotion and named parameters to model the same data. I think this is effectively a solved problem. No real debates about the 4, 6, 7 and 8, but I'm radically opposed to throwing out the baby with the bathwater here — languages that have solved these problems exist, but demanding a proposal pass a purity test means the PHP project is more likely to stay the way it is. Best wishes, Matt
