On Thu, May 15, 2025, at 2:56 PM, Rob Landers wrote: > On Thu, May 15, 2025, at 17:32, Tim Düsterhus wrote: >> Hi >> >> Am 2025-05-15 14:14, schrieb Rob Landers: >> > For example, if you have a Money type, you'd want to be able to ensure >> > it cannot be negative when updating via `with()`. This is super >> > important for ensuring constraints are met during the clone. >> >> That's why the assignments during cloning work exactly like regular >> property assignments, observing visibility and property hooks. >> >> The only tiny difference is that an “outsider” is able to change a >> `public(set) readonly` property after a `__clone()` method ran to >> completion and relied on the property in question not changing on the >> cloned object after it observed its value. This seems not to be >> something relevant in practice, because why would the exact value of the >> property only matter during cloning, but not at any other time? >> >> Best regards >> Tim Düsterhus >> > > Hey Tim, > >> why would the exact value of the >> property only matter during cloning, but not at any other time? > > For example, queueing up patches to store/db to commit later; during > the clone, it may register various states to ensure the patches are > accurate from that point. That's just one example, though, and it > suggests calling __clone *before* setting the values is the right > answer. > > I think Larry's idea of just using hooks for validation is also pretty > good. As Larry said, the only thing you can really do is throw an > exception, and the same would be true in a constructor as well. > > — Rob
The limit of hooks is that they're single-property. So depending on how your derived properties are implemented, it may be insufficient. I could easily write such an example (the hooks RFC included some), but how contrived they are, I don't know. --Larry Garfield
