Personally I still think we should have used TS/JS syntax for computed properties. PHP is much closer to typescript than Java/C# and we already have support for modifiers. Slightly more verbose but these issues would be non-existent.
On Sun, Jun 9, 2024 at 10:03 AM Nikita Popov <p...@npopov.com> wrote: > 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 >
