Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114274
MIME-Version: 1.0
References: <CAF+90c-Aeaf9SfkCZWC-NZ4dy+8HxE2V=7oa94TO2zkAf2kaQQ@mail.gmail.com>
 <CADyq6sLx9239Wp0MfofAjCQYatPiY58Xw0F9-c7qnyhAZ63H9w@mail.gmail.com> <CAF+90c_w3bm=nJ3+vSz=6rg4tAETkcND4hos24Cx+ZuXWn5c5A@mail.gmail.com>
In-Reply-To: <CAF+90c_w3bm=nJ3+vSz=6rg4tAETkcND4hos24Cx+ZuXWn5c5A@mail.gmail.com>
Date: Tue, 4 May 2021 18:32:31 +0200
Message-ID: <CADyq6s+JYng9eE-QtV9vfJ3=DsrX1dLMPWXrwvwnJY-=d3UE6A@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000aadceb05c183a003"
Subject: Re: [PHP-DEV] [RFC] Property accessors
From: ocramius@gmail.com (Marco Pivetta)

--000000000000aadceb05c183a003
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey NikiC,
<http://ocramius.github.com/>


On Tue, May 4, 2021 at 4:21 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> 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),
>>> and
>>> 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 accesso=
rs
>>> 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 o=
f
>> 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.
>>
>
> 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 question=
s
> regarding compatibility during inheritance though.
>
> Of course, I am generally sympathetic towards killing references with fir=
e
> :)
>

I'd strongly advise killing by-ref array push there: it's an acceptable
limitation, for the amount of benefit we get :P
In fact, people doing `__get` now are already familiar with "Indirect
modification of overloaded property" (https://3v4l.org/6dTXK)

As for use-cases around using by-ref, it is true that some of my libraries
use by-ref to shadow/override object properties, but I'd rather kill the
library than have by-ref proliferation.


>  * what does an array cast of an object with accessors look like? I assum=
e
>> 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_e=
tc
> (I've renamed the section to make it clearer.)
>

Thanks! Perhaps I missed it :-)


>  * 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
>>
>
> 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)?
>

From this example:

class Test {
    // Illegal: "public get" has higher visibility than "private $prop".
    private string $prop { public get; set; }

    // Illegal: "public get" has same visibility as "public $prop".
    // This visibility modifier is redundant and must be omitted.
    public string $prop { public get; private set; }}


I'd perhaps mis-interpreted the error? Why is `public get` illegal? Also,
is the example missing inheritance?


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--000000000000aadceb05c183a003--