Re: RFC: Add `final class Vector` to PHP

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