Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114266
MIME-Version: 1.0
References: <CAF+90c-Aeaf9SfkCZWC-NZ4dy+8HxE2V=7oa94TO2zkAf2kaQQ@mail.gmail.com>
In-Reply-To: <CAF+90c-Aeaf9SfkCZWC-NZ4dy+8HxE2V=7oa94TO2zkAf2kaQQ@mail.gmail.com>
Date: Tue, 4 May 2021 12:57:50 +0200
Message-ID: <CADyq6sLx9239Wp0MfofAjCQYatPiY58Xw0F9-c7qnyhAZ63H9w@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000bd46d705c17ef341"
Subject: Re: [PHP-DEV] [RFC] Property accessors
From: ocramius@gmail.com (Marco Pivetta)

--000000000000bd46d705c17ef341
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey NikiC,

On Tue, May 4, 2021, 12:34 Nikita Popov <nikita.ppv@gmail.com> wrote:

> Hi internals,
>
> I'd like to present an RFC for property accessors:
> https://wiki.php.net/rfc/property_accessors
>
> Property accessors are like __get() and __set(), but for a single propert=
y.
> They also support read-only properties and properties with asymmetric
> visibility (public read, private write) as a side-effect.
>
> The proposal is modeled after C#-style accessors (also used by Swift), an=
d
> syntactically similar to the previous
> https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 proposal.
>
> 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.
>
> 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.
>

I've skimmed the RFC: it will take a lot of testing to see how much this
impacts BC, but potentially a lot.

A few things that came up so far:

 * instead of allowing by-ref `get` declaration, can we just kill it here,
before it breeds again? I don't think I need to explain the woes of by-ref
to internals, but removing the ability to declare new accessors by-ref
would be a huge win for the engine and the language long-term.
 * what does an array cast of an object with accessors look like? I assume
only properties backed by storage will appear? (Yes, the array cast is
still the simplest/most useful pure API to inspect object state =F0=9F=98=
=81)
 * what is the design decisions around same-visibility declarations causing
compile errors in inheritance scenarios? Those would make BC unnecessarily
complex, if a parent type declares a new accessor with the same name:
variance is understandable, but same visibility errors seem a bit too much

As for the rest: it needs more careful review.
So far, good work!

>

--000000000000bd46d705c17ef341--