On Mon, Apr 15, 2024, at 18:43, Larry Garfield wrote: > The vote for the Property Hooks RFC is now open: > > https://wiki.php.net/rfc/property-hooks > > Voting will close on Monday 29 April, afternoonish Chicago time.
I know I'm a few months late on this one, but I figured I'd still leave a couple of thoughts... Overall, the proposal is well thought out and does address many of the reservations I had about my original accessors proposal. One of the more interesting choices in this proposal is to base whether the property is virtual or backed on the presence of a "$this->prop" reference in the accessor implementation. I think that, conceptually at least, this is a good choice. What I find concerning though, is that the presence/absence of such a reference also affects the meaning of the get and set hooks. If the property is virtual and it only has get, then the property cannot be set. If the property is backed and only has get, then the property *can* be set. A no-op setter is implied. (Similar for only having a set hook.) This has the unfortunate consequence that you actually have to look at the accessor implementation to determine the API of the class -- only looking at the "prototypes" (i.e. signatures without implementation bodies) is no longer sufficient! This seems both unfortunate and unprecedented. This could have been avoided by still requiring an explicit no-op "set;" at the expensive of some additional verbosity. The other thing that stood out to me are the short-hand notations using =>. There was a prior RFC on the topic (https://wiki.php.net/rfc/short-functions), which has been declined. That RFC would have introduced => ... as a general shorthand for { return ...; }. The shorthand notation for get is compatible with that formulation. However, the shorthand notation for set is not. In that case => ... isn't short for { return ...; }, but rather for { $this->prop = ...; }. This seems pretty unfortunate to me, and possibly closes the door on revisiting a general short function syntax in the future. Mostly I'm scratching my head at why this was included in the proposal at all, as I would not expect this use of the set hook to be common enough to justify a shorthand. The common case is a guard that checks the value without modifying it. Putting this to the "would this shorthand have passed if it were introduced by a separate RFC on top of the base implementation" test, I think the answer would have been a clear "no". Regards, Nikita
