Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122612
Precedence: bulk
MIME-Version: 1.0
References: <fca97d6c-d4ec-4000-958a-72c32beb8421@app.fastmail.com>
 <CAJp_myUayeQ=irpFUG0OrUj=PjE3_mx395h_ARSdLmdyEB6_EQ@mail.gmail.com>
 <790b5b4e-f51b-4050-a12a-5fa903d0568f@app.fastmail.com> <CA+hqhpe5k0+qPezkgo9JdVyfmGan7DYPgmp7aGecSQokmArPiw@mail.gmail.com>
In-Reply-To: <CA+hqhpe5k0+qPezkgo9JdVyfmGan7DYPgmp7aGecSQokmArPiw@mail.gmail.com>
Date: Mon, 11 Mar 2024 17:13:37 +0100
Message-ID: <CA+hqhpe+6rkskveFO+OzesdbqVTwvrb2pRn+jjvmcTyz+AbZiQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: weirdan@gmail.com (Bruce Weirdan)

On Tue, Feb 27, 2024 at 6:22=E2=80=AFPM Bruce Weirdan <weirdan@gmail.com> w=
rote:
>
> Hi Larry and others
>
> On Fri, Feb 23, 2024 at 12:57=E2=80=AFAM Larry Garfield <larry@garfieldte=
ch.com> wrote:
> >
> >
> > I've added an FAQ section explaining why the Python/JS approach wouldn'=
t really work.  To be clear, Ilija and I spent 100+ hours doing research an=
d design before we started implementation (back in mid-late 2022).  We did =
seriously consider the JS-style syntax, but in the end we found it created =
more problems than it solves.  For the type of language PHP is (explicit ty=
ped properties), doing it on the property itself is a much cleaner approach=
.
>
>
> The section you added [1] seems to focus on having both `public string
> $fistName` and `public function get/set firstName():string`, and how
> it's hard to keep types and visibility in sync. But I'm not sure if
> you considered making properties and accessors mutually exclusive. I
> mean the following:
>
> ```php
> class Person
> {
>     public string $firstName;      // compile time error, setter/getter d=
efined
>
>     public function __construct(private string $first, private string $la=
st) {}
>
>     public function get firstName(): string       // compile time
> error, property defined
>     {
>         return $this->first . " " . $this->last;
>     }
>
>     public function set firstName(string $value): void     // compile
> time error, property defined
>     {
>         [$this->first, $this->last] =3D explode(' ', $value);
>     }
> }
> ```
>
> This seems to address most of the counterpoints you listed, to some degre=
e:
>
> > What is the property type of the $firstName property?
>
> Well, you propose to allow wider write-types yourself, so the question
> would apply there as well. But presumably, the property type is its
> read type - so whatever getter returns.
>
> > but there's nothing inherent that forces, public string $firstName, get=
 firstName()s return and set firstName()s parameter to be the same. Even if=
 we could detect it as a compile error, it means one more thing that the de=
veloper has to keep track of and get right, in three different places.
>
> With mutually exclusive accessors and properties it becomes just two
> places. And yes, accessor consistency would need to be checked at
> compile time. But the same can be said for the widening of write type
> you proposed.
>
> > What about visibility? Do the get/set methods need to have the same vis=
ibility as the property?
>
> When there's no property the question becomes moot.
>
> > If not, does that become a way to do asymmetric visibility?
>
> Yes.
>
> > What about inconsistency between the method's visibility and the proper=
ty visibility? How is that handled?
>
> There's no inconsistency when there's no property. Accessor visibility
> can be different - allowing the asymmetric visibility you wanted to
> implement in your other RFC.
>
> > How do you differentiate between virtual and non-virtual properties?
>
> This one is hard to answer without asking another question: why would
> you need to? Does the requirement to know it stem from engine
> implementation details, or do you need as a person writing code in
> PHP?
>
> > For non-virtual properties, if you need to triple-enter everything, we'=
re back to constructors pre-promotion. Plus, the accessor methods could be =
anywhere in the class, potentially hundreds of lines away. That means just =
looking at the property declaration doesn't tell you what its logic is; the=
 logic may be on line 960, which only makes keeping its type/visibility in =
sync with the property harder.
>
> Forbidding property declaration reduces that to double. The rest is
> mostly stylistic and can be said about traditional
> (non-constructor-promoted) properties as well.
>
> Now this approach naturally has some open questions, foremost about
> inheritance. But we probably don't need to go into those details if
> you already explored this way and found some technical obstacles. If
> you did, it would probably make sense to list them in the FAQ section.
>
> [1] https://wiki.php.net/rfc/property-hooks#why_not_pythonjavascript-styl=
e_accessor_methods


Resending this since I've never got a reply and it's quite possible
the message got lost due to mail list issues.

--=20
  Best regards,
      Bruce Weirdan                                     mailto:weirdan@gmai=
l.com