Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110863
User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668
Mime-Version: 1.0
Message-ID: <3ea6fb8c-b088-463b-b5be-cecf6056f89b@www.fastmail.com>
In-Reply-To: 
 <CAHRtwKagcmkz3VpHwpBsGn59w9OaWgHLr+WfVtgJWbDfUmbjcA@mail.gmail.com>
References: 
 <CAHRtwKbbsoh4kT5++43yJg9RH+aNnRCAiE+yLOO7tOfMjcjBGg@mail.gmail.com>
 <CAF+90c9E4Aq9reaDFE2JhzzXHX9Qoi+DsDiyNFgDupFBA+pmuA@mail.gmail.com>
 <CAHRtwKagcmkz3VpHwpBsGn59w9OaWgHLr+WfVtgJWbDfUmbjcA@mail.gmail.com>
Date: Tue, 07 Jul 2020 10:02:20 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Property write visibility
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Jul 7, 2020, at 2:35 AM, Andr=C3=A9 R=C3=B8mcke wrote:
> >
> > ergonomic, and in the case of magic method usage improve performance=
.
> >>
> >
> > I think this is a good direction to explore, but would recommend del=
aying
> > it until PHP 8.1. As the RFC and discussion note, the design space h=
ere
> > overlaps significantly with both readonly/immutability and property
> > accessors. We should take enough time to consider these
> > alternatives/extensions as well, to ensure that we don't end up with=

> > multiple distinct and possibly incompatible mechanisms. We don't hav=
e that
> > time before PHP 8.0 feature freeze.
> >
>=20
>=20
> I've updated the RFC to rather aim for 8.1, I fully agree this should =
in
> any form be made asure to align well with the related requests. Larrye=
's
> email is a good example of what kind the language might look like when=

> several such features are potentially accepted in the future.
>=20
> May I propose that some of us interested in this do a short call over =
the
> summer on this topic to see if we can align on direction?

I'm open to that.  Explicit design process FTW.

--Larry Garfield