Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122448
Precedence: bulk
MIME-Version: 1.0
References: <fca97d6c-d4ec-4000-958a-72c32beb8421@app.fastmail.com>
In-Reply-To: <fca97d6c-d4ec-4000-958a-72c32beb8421@app.fastmail.com>
Date: Wed, 21 Feb 2024 17:02:38 -0600
Message-ID: <CAJp_myUayeQ=irpFUG0OrUj=PjE3_mx395h_ARSdLmdyEB6_EQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006d3d010611ec5304"
From: mweierophinney@gmail.com ("Matthew Weier O'Phinney")

--0000000000006d3d010611ec5304
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 21, 2024 at 12:57=E2=80=AFPM Larry Garfield <larry@garfieldtech=
.com>
wrote:

> After much on-again/off-again work, Ilija and I are back with a more
> polished property access hooks/interface properties RFC.  It=E2=80=99s 99=
%
> unchanged from last summer; the PR is now essentially complete and more
> robust, and we were able to squish the last remaining edge cases.
>
> Baring any major changes, we plan to bring this to a vote in mid-March.
>
> https://wiki.php.net/rfc/property-hooks
>
> It=E2=80=99s long, but that=E2=80=99s because we=E2=80=99re handling ever=
y edge case we could
> think of.  Properties involve dealing with both references and inheritanc=
e,
> both of which have complex implications.  We believe we=E2=80=99ve identi=
fied the
> most logical handling for all cases, though.
>

Once again in reading the proposal, the first thing I'm struck by are the
magic "$field" and "$value" variables inside accessors. The first time they
are used, they're used without explanation, and they're jarring.

Additionally, once you start defining the behavior of accessors... you
don't start with the basics, but instead jump into some of the more
esoteric usage, which does nothing to help with the questions I have.

So, first:

- Start with the most basic, most expected usage for each of reading and
writing properties.
- I need a better argument for why the $field and $value variables exist.
Saying they're macros doesn't help those not deep into internals. As a
user, why do they exist?

Honestly, it's not obvious at all that I can just set something to the
variable "$field", and if I didn't know about the feature and stumbled
across a class that used accessors, I'd be wondering what "$field" is, and
how the property ever gets set. (And yes, I've read the FAQ. Saying it's
used in another language doesn't automatically make it good design.)

I know you say in the narrative that you _can_ use `$this->propertyName =3D=
 `
to set the value, but you also say it's _not recommended_ (though you do
not indicate _why_). To somebody coming primarily from userland who's been
doing OOP in PHP for over 20 years, it's far more clear what's happening.
Alternately, I'd argue that both the accessors should require an argument
that represents the reference to the property:

    public string $username {
        set($field, string|Stringable $value) {
            $field =3D (string) $value;
        }
        get ($field) =3D> strtolower($field);
    }

The same is true for $value. I'd recommend only ever allowing the construct
`set ($value) {}`, as it's immediately clear that `$value` is the argument
and value being provided to the accessor. When it's implicit, it's easy to
lose context.

Second: you don't have examples of defining BOTH get and set OTHER than
when using expressions for both accessors or a mix. I'm actually unclear
what the syntax is when both are defined. Is there supposed to be a `;`
terminating each? Or  a `,`? Or just an empty line? Again, this is one of
the more common scenarios. It needs to be covered early, and clearly.

Third: the caveats around usage with arrays... give me pause. While I'm
personally trying to not use arrays as much as possible, a lot of code I
see or contribute to still does, and the fact that an array property that
uses a write accessor doesn't allow the same level of access as a normal
array property is something I see leading to a lot of confusion and errors.
I don't have a solution, but I worry that this one thing alone could be
enough to prevent the passage of the RFC.

Fourth: the syntax around inheritance is not intuitive, as it does not work
in the same way as the rest of the language. I'm talking about this:

    public int $x {
        get: 2 * parent::$x::get()
    }

Why do we need to use the accessors here? Why wouldn't it just be
`parent::$x`?

I want to be clear: I really like the idea behind this feature, and
overall, I appreciate the design. From a user perspective, though, the
above are things that I found jarring as they vary quite a bit from our
current language design.

>
> Note the FAQ question at the end, which explains some design choices.
>
> There=E2=80=99s one outstanding question, which is slightly painful to as=
k:
> Originally, this RFC was called =E2=80=9Cproperty accessors,=E2=80=9D whi=
ch is the
> terminology used by most languages.  During early development, when we ha=
d
> 4 accessors like Swift, we changed the name to =E2=80=9Chooks=E2=80=9D to=
 better indicate
> that one was =E2=80=9Chooking into=E2=80=9D the property lifecycle.  Howe=
ver, later
> refinement brought it back down to 2 operations, get and set.  That makes
> the =E2=80=9Chooks=E2=80=9D name less applicable, and inconsistent with w=
hat other
> languages call it.
>
> However, changing it back at this point would be a non-small amount of
> grunt work. There would be no functional changes from doing so, but it=E2=
=80=99s
> lots of renaming things both in the PR and the RFC. We are willing to do =
so
> if the consensus is that it would be beneficial, but want to ask before
> putting in the effort.
>

I personally would go with just "accessors".


--=20
Matthew Weier O'Phinney
mweierophinney@gmail.com
https://mwop.net/
he/him

--0000000000006d3d010611ec5304
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 21, 2024 at 12:57=E2=80=
=AFPM Larry Garfield &lt;<a href=3D"mailto:larry@garfieldtech.com">larry@ga=
rfieldtech.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">
After much on-again/off-again work, Ilija and I are back with a more polish=
ed property access hooks/interface properties RFC.=C2=A0 It=E2=80=99s 99% u=
nchanged from last summer; the PR is now essentially complete and more robu=
st, and we were able to squish the last remaining edge cases.<br>
<br>
Baring any major changes, we plan to bring this to a vote in mid-March.<br>
<br>
<a href=3D"https://wiki.php.net/rfc/property-hooks" rel=3D"noreferrer" targ=
et=3D"_blank">https://wiki.php.net/rfc/property-hooks</a><br>
<br>
It=E2=80=99s long, but that=E2=80=99s because we=E2=80=99re handling every =
edge case we could think of.=C2=A0 Properties involve dealing with both ref=
erences and inheritance, both of which have complex implications.=C2=A0 We =
believe we=E2=80=99ve identified the most logical handling for all cases, t=
hough.<br></blockquote><div><br></div><div>Once again in reading the propos=
al, the first thing I&#39;m struck by are the magic &quot;$field&quot; and =
&quot;$value&quot; variables inside accessors. The first time they are used=
, they&#39;re used without explanation, and they&#39;re jarring.</div><div>=
<br></div><div>Additionally, once you start defining the behavior of access=
ors... you don&#39;t start with the basics, but instead jump into some of t=
he more esoteric usage, which does nothing to help with the questions I hav=
e.</div><div><br></div><div>So, first:</div><div><br></div><div>- Start wit=
h the most basic, most expected usage for each of reading and writing prope=
rties.</div><div>- I need a better argument for why the $field and $value v=
ariables exist. Saying they&#39;re macros doesn&#39;t help those not deep i=
nto internals. As a user, why do they exist?</div><div><br></div><div>Hones=
tly, it&#39;s not obvious at all that I can just set something to the varia=
ble &quot;$field&quot;, and if I didn&#39;t know about the feature and stum=
bled across a class that used accessors, I&#39;d be wondering what &quot;$f=
ield&quot; is, and how the property ever gets set. (And yes, I&#39;ve read =
the FAQ. Saying it&#39;s used in another language doesn&#39;t automatically=
 make it good design.)=C2=A0</div><div><br></div><div>I know you say in the=
 narrative that you _can_ use `$this-&gt;propertyName =3D ` to set the valu=
e, but you also say it&#39;s _not recommended_ (though you do not indicate =
_why_). To somebody coming primarily from userland who&#39;s been doing OOP=
 in PHP for over 20 years, it&#39;s far more clear what&#39;s happening. Al=
ternately, I&#39;d argue that both the accessors should require an argument=
 that represents the reference to the property:</div><div><br></div><div>=
=C2=A0=C2=A0=C2=A0 public string $username {</div><div>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 set($field, string|Stringable $value) {</div><div>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 $field =
=3D (string) $value;<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 }</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 get ($field) =3D=
&gt; strtolower($field);<br></div><div>=C2=A0=C2=A0=C2=A0 }<br></div><div><=
br></div><div>The same is true for $value. I&#39;d recommend only ever allo=
wing the construct `set ($value) {}`, as it&#39;s immediately clear that `$=
value` is the argument and value being provided to the accessor. When it=
9;s implicit, it&#39;s easy to lose context.</div><div><br></div><div>Secon=
d: you don&#39;t have examples of defining BOTH get and set OTHER than when=
 using expressions for both accessors or a mix. I&#39;m actually unclear wh=
at the syntax is when both are defined. Is there supposed to be a `;` termi=
nating each? Or=C2=A0 a `,`? Or just an empty line? Again, this is one of t=
he more common scenarios. It needs to be covered early, and clearly.<br></d=
iv><div><br></div><div>Third: the caveats around usage with arrays... give =
me pause. While I&#39;m personally trying to not use arrays as much as poss=
ible, a lot of code I see or contribute to still does, and the fact that an=
 array property that uses a write accessor doesn&#39;t allow the same level=
 of access as a normal array property is something I see leading to a lot o=
f confusion and errors. I don&#39;t have a solution, but I worry that this =
one thing alone could be enough to prevent the passage of the RFC.</div><di=
v><br></div><div>Fourth: the syntax around inheritance is not intuitive, as=
 it does not work in the same way as the rest of the language. I&#39;m talk=
ing about this:</div><div><br></div><div>=C2=A0=C2=A0=C2=A0 public int $x {=
</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 get: 2 * parent::$x::=
get()</div><div>=C2=A0=C2=A0=C2=A0 }</div><div><br></div><div>Why do we nee=
d to use the accessors here? Why wouldn&#39;t it just be `parent::$x`?</div=
><div><br></div><div>I want to be clear: I really like the idea behind this=
 feature, and overall, I appreciate the design. From a user perspective, th=
ough, the above are things that I found jarring as they vary quite a bit fr=
om our current language design.<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">
<br>
Note the FAQ question at the end, which explains some design choices.<br>
<br>
There=E2=80=99s one outstanding question, which is slightly painful to ask:=
 Originally, this RFC was called =E2=80=9Cproperty accessors,=E2=80=9D whic=
h is the terminology used by most languages.=C2=A0 During early development=
, when we had 4 accessors like Swift, we changed the name to =E2=80=9Chooks=
=E2=80=9D to better indicate that one was =E2=80=9Chooking into=E2=80=9D th=
e property lifecycle.=C2=A0 However, later refinement brought it back down =
to 2 operations, get and set.=C2=A0 That makes the =E2=80=9Chooks=E2=80=9D =
name less applicable, and inconsistent with what other languages call it.<b=
r>
<br>
However, changing it back at this point would be a non-small amount of grun=
t work. There would be no functional changes from doing so, but it=E2=80=99=
s lots of renaming things both in the PR and the RFC. We are willing to do =
so if the consensus is that it would be beneficial, but want to ask before =
putting in the effort.<br></blockquote><div><br></div><div>I personally wou=
ld go with just &quot;accessors&quot;. <br></div></div><div class=3D"gmail_=
quote"><br></div><div class=3D"gmail_quote"><br></div><span class=3D"gmail_=
signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature">=
<div dir=3D"ltr"><div>Matthew Weier O&#39;Phinney<br><a href=3D"mailto:mwei=
erophinney@gmail.com" target=3D"_blank">mweierophinney@gmail.com</a><br><a =
href=3D"https://mwop.net/" target=3D"_blank">https://mwop.net/</a></div><di=
v>he/him<br></div></div></div></div>

--0000000000006d3d010611ec5304--