Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114270
MIME-Version: 1.0
References: <CAF+90c-Aeaf9SfkCZWC-NZ4dy+8HxE2V=7oa94TO2zkAf2kaQQ@mail.gmail.com>
 <CADyq6sLx9239Wp0MfofAjCQYatPiY58Xw0F9-c7qnyhAZ63H9w@mail.gmail.com>
In-Reply-To: <CADyq6sLx9239Wp0MfofAjCQYatPiY58Xw0F9-c7qnyhAZ63H9w@mail.gmail.com>
Date: Tue, 4 May 2021 16:21:23 +0200
Message-ID: <CAF+90c_w3bm=nJ3+vSz=6rg4tAETkcND4hos24Cx+ZuXWn5c5A@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000edd80405c181cb18"
Subject: Re: [PHP-DEV] [RFC] Property accessors
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000edd80405c181cb18
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 4, 2021 at 12:58 PM Marco Pivetta <ocramius@gmail.com> wrote:

> 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
>> property.
>> 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), a=
nd
>> 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 implementatio=
n,
>> I've grown increasingly uncertain that this is the right direction for u=
s
>> to take. The proposal turned out to be significantly more complex than I
>> originally anticipated (despite reducing the scope to only "get" and "se=
t"
>> 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 accessor=
s
>> proposal would be captured by support for read-only (and/or private-writ=
e)
>> 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-re=
f
> 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.
>

The primary functionality by-ref get is needed for are operations on
arrays, such as $foo->bar[] =3D $val. This probably isn't particularly
important for explicit accessors, but may be a non-trivial limitation for
implicit ones. For example, you wouldn't be able to have a "public get,
private set" on an array property, for all practical purposes. Of course,
we could allow that to work fine for implicit accessors, without any
by-value vs by-reference get distinction. Would probably open up questions
regarding compatibility during inheritance though.

Of course, I am generally sympathetic towards killing references with fire
:)

 * 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)
>

That's correct. This is mentioned in
https://wiki.php.net/rfc/property_accessors#var_dump_array_cast_foreach_etc
(I've renamed the section to make it clearer.)

 * what is the design decisions around same-visibility declarations causing
> compile errors in inheritance scenarios? Those would make BC unnecessaril=
y
> complex, if a parent type declares a new accessor with the same name:
> variance is understandable, but same visibility errors seem a bit too muc=
h
>

I'm not sure which error you're referring to here. Could you share an
example (or point me to the example in the RFC)?

Regards,
Nikita

--000000000000edd80405c181cb18--