Hi Rob
On Sun, Nov 17, 2024 at 12:15 AM Rob Landers <rob@bottled.codes> wrote: > > Hello internals, > > I'm ready as I'm going to be to introduce to you: "Records" > https://wiki.php.net/rfc/records! Thanks for your proposal. I very much agree that value semantics are a highly desirable feature. I sent out my concept proposal on how this may be achieved through structs some months ago. [1] There are some remaining technical challenges, but the PoC looks promising. [2] I personally do not think immutable data structures are a good solution to the problem, and I don't feel like we need another, slightly shorter way to do the same thing. In my proposal, I mentioned that there are two primary issues with immutable data structures: 1. They are expensive. Any modification of the class requires a clone of the object by design, even when the cloned object is immediately discarded. This is most noticeable for lists and other growable data types, because they are large and change frequently. An O(n) insertion becomes infeasible very fast. 2. The clone is explicit, which gets old pretty quickly. Many of PHPs quality-of-life features like op-assign (e.g. +=) become unusable. Structs would instead be fully-fledged objects that adopt CoW (copy-on-write) semantics, which is how PHP already implements arrays. Essentially, objects are automatically cloned when they are changed _and_ when the object is referenced from multiple places. If the object is not referenced anywhere else, it may be safely mutated without a clone, as there is nobody to observe this side-effect. When a shared object is mutated multiple times (e.g. an append to a list in a loop), only the first mutation requires a clone. It's also something you don't need to think about, it just happens. As mentioned, the main motivation of my proposal is to implement new dedicated data structures like Vectors, Maps, Sets, etc. in PHP (userland and extensions) without sacrificing ergonomics or performance. However, they would also solve the same challenges for simple data objects. IMO, immutability was never a great solution to the problem of "spooky action at a distance". Mutability itself is not a problem, just shared mutability. Note that this concept is heavily inspired by Swift, Rust and likely other languages I don't know. Chris Lattner (the original author of LLVM and Swift) has shared very similar thoughts in an interview recently. [3] If the primary motivation of your RFC is to reduce boilerplate, then it's true that structs would not help much. I do wonder whether 1. we need even shorter code and 2. if we do, whether it's something that could be added to classes alike, rather than tying it to records when it could be more generic instead. A small note: The $test = &Test(); syntax is ambiguous, as it's already legal. https://3v4l.org/CE5rt Ilija [1] https://externals.io/message/122845 [2] https://github.com/php/php-src/pull/13800 [3] https://youtu.be/JRcXUuQYR90?si=p51_x3wkfeeeGfq-&t=3319
