On 16/03/2024 17:51, Ilija Tovilo wrote:
Properties can inherit both storage and hooks from their parent.
Hopefully, that helps with the mental model. Of course, in reality it
is a bit more complicated due to guards and references.
That is a really helpful explanation, thanks; I hadn't thought about the
significance of inheritance between hooked and non-hooked properties.
I still think there will be a lot of users coming from other languages,
or from using __get and __set, who will look at virtual properties
first. Making things less surprising for those people seems worth some
effort, but I'm not asking for a complete redesign.
Dynamic properties are not particularly relevant today. The point was
not to show how similar these two cases are, but to explain that
there's an existing mechanism in place that works very well for hooks.
We may invent some new mechanism to access the backing value, like
`field = 'value'`, but for what reason? This would only make sense if
the syntax we use is useful for something else. However, given that
without guards it just leads to recursion, which I really can't see
any use for, I don't see the point.
I can think of several reasons we *could* explore other syntax:
1) To make it clearer in code whether a particular line is accessing via
the hooks, or by-passing them 2) To make the code in the hooks shorter
(e.g. `$field` is significantly shorter than
`$this->someDescriptiveName`) 3) To allow code to by-pass the hooks at
will, rather than only when called from the hooks (e.g. having a single
method that resets the state of several lazy-loaded properties)
Those reasons are probably not enough to rule out the current syntax;
but they show there are trade-offs being made.
To be honest, my biggest hesitation with the RFC remains asymmetric
types (the ability to specify types in the set hook). It's quite a
significant feature, with no precedent I know of, and I'm worried we'll
overlook something by including it immediately. For instance, what will
be the impact on people using reflection or static analysis to reason
about types? I would personally be more comfortable leaving that to a
follow-up RFC to consider the details more carefully.
Nobody else has raised that, beyond the syntax; I'm not sure if that's
because everyone is happy with it, or because the significance has been
overlooked.
Regards,
--
Rowan Tommins
[IMSoP]
