On 16 March 2019 05:18:55 GMT+00:00, Larry Garfield <la...@garfieldtech.com> wrote: >In general, though, I think beefing up objects to be "more usable as >structs" (locked against dynamic properties, getter/setter methods, >possibly some improved tooling for with*()-style behavior, etc.) is the >more sustainable long-term solution than adding an entirely new >language construct.
Hi Larry, That's a great summary, and I agree that structs make most sense viewed as an object with special behaviours, rather than a completely separate type. Native support for "evolvable" objects (withFoo methods) would be interesting, although I'm not sure what it would look like - ideally, it would reduce both the boilerplate of declaring them, and the overhead of creating intermediate objects when evolving more than one property. It's still more verbose to write than direct assignment to a property, but no more so than calling a setter method explicitly. One thing that hasn't been brought up yet is identity: if structs are just a special kind of object, you would be able to compare them by identity; if they are more like arrays, you would only be able to compare them by value. I think not having identity would make sense, both because of the expected use cases, and because it plays better with copy-on-write optimisations: $x = new SomeStruct { foo=0 }; $x = $y; // copy-by-value, but optimised internally to copy-on-write var_dump($x === $y); // true? at this point, there is no new object identity $y->foo = 1; // copy-on-write triggers internally var_dump($x === $y); // false? they are now separated $y->foo = 0; var_dump($x === $y); // false? structs are now identical again, but separated in memory This is much more intuitive if structs have no identity, and any two instances with the same values are considered identical. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php