Hi Larry Garfield, > Rather than go point by point, I'm going to respond globally here. > > 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. > > This proposal addresses the first point and... that's it. Point 5 is sort of > covered by virtue of being out of scope, so maybe this covers 1.5 out of 8. > That's insufficient to be worth the effort to support and deal with in code. > That makes this approach a strong -1 for me. > > "Fancy algorithms are slow when n is small, and n is usually small." -- Rob > Pike > > That some of the design choices here mirror existing poor implementations is > not an endorsement of them. I don't think I've seen anyone on this list say > anything good about SPL beyond iterators and autoloading, so it's not really > a good model to emulate. > > Additionally, please don't play into the trope about procedural/mutable code > being more beginner friendly. That's not the case, beyond being a > self-fulfilling prophesy. (If we teach procedural/mutable code first, then > most beginners will be most proficient in procedural/mutable code.) I would > argue that, on the whole, immutable values make code easier to reason about > and write once you get past trivially small sizes. We do new developers a > gross disservice by treating immutability as an "advanced" technique, when it > should really be the default, beginner technique taught from day one. > > I am not aware of any PECL implementations of lists that have type safety, > because I don't use many PECL packages. However, in user space it's quite > simple to do: > > https://presentations.garfieldtech.com/slides-never-use-arrays/phpkonf2021/#/5/2 > > See that slide and scroll down for additional examples. Every one of those > examples took me less than 5 minutes to write. If we want to have a better > alternative in core, it needs to be *at least* as capable as what I can throw > together in 5 minutes. The proposal as-is is not even as capable as those > examples.
Yes, you can implement those immutable and typed data structures in userland. You are doing that by adding userland code hiding the internal implementations of the mutable `array` to solve the needs of your library/application (e.g. those 8). Adding a mutable `Vector` gives another way to internally represent those userland data structures when you need those userland data structures to share data internally without using PHP references (not as part of the public api), e.g. appending to a list of error objects, performing a depth-first search or breadth-first search, etc. As for your example, it's impossible to type hint without generics, and nobody's working on generics. If I have your userland `TypedArray::forType(MyClass::class);`, I can pass it to any parameter/return value/property expecting a `TypedArray`, but that will then throw an Error at runtime with no warning ahead of time if I pass it to a function expecting a `TypedArray` of `OtherClass`. Static analyzers exist separately from php that could analyze that, but 1. Many developers wouldn't have static analyzers set up. 2. The TypedArrays may be created from unserialization from apcu/memcache/redis and be impractical to analyze (e.g. from an older release of a library or application) 3. Voters may object to this additional way to write PHP code that could error at runtime. **What data structures do you want in core? Do you want them to eagerly evaluate generators or lazily evaluate them? Is `TypedArray` or `TypedSequence` something you think should have an RFC or plan to create an RFC for?** Even if immutable data structures are proposed, there's a further division between programmers who want lazy or eager immutables (e.g. their constructors or factory methods to eagerly evaluate iterable values or lazily evaluate values), and there may be enough objections to either choice (for the specific data structure proposed) when it was time to actually vote to result in the vote failing. (in addition to other objections that come up in any new proposal for core datastructures) This discourages me from proposing immutable data structures. I'd agree on the utility of Set/Map/sorted data structures (though the hashable vs not hashable, comparator vs no comparator, how to hash, etc. is a discussion that I believe would be time consuming and hasn't happened yet). Because PHP has no stack overflow/recursion depth detection and just segfaults at runtime, I believe strict `===` equality like that example and like JavaScript https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map would be the most appropriate for an proposal made long after PHP was released. But while I'm open to adding immutable data structures, the mutable datastructures should also exist in many cases, and I believe immutable should be named or namespaced that way. Thanks, Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
