Re: [RFC][Vote] Property Hooks
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
Thread (8 messages)