Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114299
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\))
In-Reply-To: <CAF+90c-Aeaf9SfkCZWC-NZ4dy+8HxE2V=7oa94TO2zkAf2kaQQ@mail.gmail.com>
Date: Fri, 7 May 2021 23:57:32 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <DC78DFD9-7188-444D-A2F7-992D3C8A73A9@newclarity.net>
References: <CAF+90c-Aeaf9SfkCZWC-NZ4dy+8HxE2V=7oa94TO2zkAf2kaQQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Property accessors
From: mike@newclarity.net (Mike Schinkel)

> On May 4, 2021, at 6:33 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
>=20
> Hi internals,
>=20
> I'd like to present an RFC for property accessors:
> https://wiki.php.net/rfc/property_accessors
>=20
> Property accessors are like __get() and __set(), but for a single =
property.
> They also support read-only properties and properties with asymmetric
> visibility (public read, private write) as a side-effect.
>=20
> The proposal is modeled after C#-style accessors (also used by Swift), =
and
> syntactically similar to the previous
> https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 proposal.
>=20
> While I put a lot of effort into both the proposal and the =
implementation,
> I've grown increasingly uncertain that this is the right direction for =
us
> to take. The proposal turned out to be significantly more complex than =
I
> originally anticipated (despite reducing the scope to only "get" and =
"set"
> accessors), and I'm sure there are some interactions I still haven't
> accounted for. I'm not convinced the value justifies the complexity.

This is an amazingly comprehensive proposal and I commend you for all =
the effort.

> So, while I'm putting this up for discussion, it may be that I will =
not
> pursue landing it. I think a lot of the practical value of this =
accessors
> proposal would be captured by support for read-only (and/or =
private-write)
> properties. This has been discussed (and declined) in the past, but
> probably should be revisited.

Adding property accessors to PHP could significantly improve robustness =
in userland code. The KEY benefit is how userland classes could evolve =
in complexity as required *without* breaking a classes' API. That =
benefit cannot be overstated IMO.

If this proposal needs to change, I hope you continue to ensure it can =
provide zero breakage during evolution of userland code.

-Mike
P.S. I also concur with Larry Garfield and am uncomfortable with the =
magic `$value` variable. I would prefer to always be explicitly =
specified in parens on =E2=80=94 e.g. `set($var)` =E2=80=94 if it needs =
to be used in the RHS of an assignment inside the set block. But this is =
a trivial concern compared to the KEY benefit mentioned above.