On 16 March 2019 05:18:55 GMT+00:00, Larry Garfield <[email protected]>
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
