Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122679
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: Mon, 18 Mar 2024 10:13:28 +0100
Message-ID: <CANS-=pc8HhX0X1FqpnU+WroXxTFAQGfhLuVi__gcue+CwXQ1fg@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="000000000000e096100613ebc67f"
From: kjarli@gmail.com (Lynn)

--000000000000e096100613ebc67f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 21, 2024 at 7:58=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com>
wrote:

> Hello again, fine Internalians.
>
> 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.
>
> 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.
>
> --
>   Larry Garfield
>   larry@garfieldtech.com


In regards to arrays, what about additional operations next to get/set? I
doubt this solution will cover all the use-cases or perhaps even
over-complicate things, just throwing the idea out there.

```php
class Test {
    private array $_myData =3D [];
    public array $myData {
        get =3D> $this->_myData;
        append =3D> $this->_myData[] =3D $value;
    }
}
```

 Thinking about the other post about offset and containers (
https://github.com/Girgias/php-rfcs/blob/master/container
-offset-behaviour.md):
```php
class Test {
    private array $_myData =3D [];
    public array $myData {
        get =3D> $this->_myData;
        append =3D> $this->_myData[] =3D $value;
        write_dimension =3D> $this->_myData[$offset] =3D $value;
    }
}
```

Is this issue restricted to arrays only? From my understanding objects
functioning as arrays are already by reference and thus should not suffer
from this?
```php
class Test {
    private ArrayObject $_myData;
    public ArrayObject $myData {
        get =3D> $this->_myData;
    }

    public function __construct() {
        $this->_myData =3D new ArrayObject();
    }
}

// would this work without issues?
$obj =3D new Test();
$obj->myData[] =3D 'test';
```

--000000000000e096100613ebc67f
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 7:58=E2=80=AF=
PM Larry Garfield &lt;<a href=3D"mailto:larry@garfieldtech.com">larry@garfi=
eldtech.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">Hello again, fine Internalians.<br>
<br>
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>
<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>
<br>
-- <br>
=C2=A0 Larry Garfield<br>
=C2=A0 <a href=3D"mailto:larry@garfieldtech.com" target=3D"_blank">larry@ga=
rfieldtech.com</a></blockquote><div><br></div><div>In regards to arrays, wh=
at about additional operations next to get/set? I doubt this solution will =
cover all the use-cases or perhaps even over-complicate things, just throwi=
ng the idea out there.</div><div><br></div><div>```php</div><div>class Test=
 {</div><div>=C2=A0 =C2=A0 private array $_myData =3D [];</div><div>=C2=A0 =
=C2=A0 public array $myData {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 get =3D=
&gt; $this-&gt;_myData;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 append =3D&gt=
; $this-&gt;_myData[] =3D $value;</div><div>=C2=A0 =C2=A0 }</div><div>}</di=
v><div>```=C2=A0</div><div><br></div><div>=C2=A0Thinking about the other po=
st about offset and containers (<a href=3D"https://github.com/Girgias/php-r=
fcs/blob/master/container-offset-behaviour.md" rel=3D"noreferrer" target=3D=
"_blank">https://github.com/Girgias/php-rfcs/blob/master/<span class=3D"gma=
il-il">container</span>-offset-behaviour.md</a>):</div><div><div>```php</di=
v><div>class Test {</div><div>=C2=A0 =C2=A0 private array $_myData =3D [];<=
/div><div>=C2=A0 =C2=A0 public array $myData {</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 get =3D&gt; $this-&gt;_myData;</div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
append =3D&gt; $this-&gt;_myData[] =3D $value;<br class=3D"gmail-Apple-inte=
rchange-newline">=C2=A0 =C2=A0 =C2=A0 =C2=A0 write_dimension =3D&gt; $this-=
&gt;_myData[$offset] =3D $value;<div>=C2=A0 =C2=A0 }</div><div>}</div></div=
><div>```</div><div><br></div><div>Is this issue restricted to arrays only?=
 From my understanding objects functioning as arrays are already by referen=
ce and thus should not suffer from this?</div><div><div><div>```php</div><d=
iv>class Test {</div><div>=C2=A0 =C2=A0 private ArrayObject=C2=A0$_myData;<=
/div><div>=C2=A0 =C2=A0 public ArrayObject=C2=A0$myData {</div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 get =3D&gt; $this-&gt;_myData;</div><div>=C2=A0 =C2=A0=
 }</div><div><br></div><div>=C2=A0 =C2=A0 public function __construct() {</=
div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 $this-&gt;_myData =3D new ArrayObject(=
);</div><div>=C2=A0 =C2=A0 }<br></div><div>}</div></div><div><br></div><div=
>// would this work without issues?</div><div>$obj =3D new Test();</div><di=
v>$obj-&gt;myData[] =3D &#39;test&#39;;</div><div>```</div></div><div><br><=
/div></div></div>

--000000000000e096100613ebc67f--