Hey NikiC, <http://ocramius.github.com/>
On Tue, May 4, 2021 at 4:21 PM Nikita Popov <nikita....@gmail.com> wrote: > On Tue, May 4, 2021 at 12:58 PM Marco Pivetta <ocram...@gmail.com> wrote: > >> Hey NikiC, >> >> On Tue, May 4, 2021, 12:34 Nikita Popov <nikita....@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 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. >> > > The primary functionality by-ref get is needed for are operations on > arrays, such as $foo->bar[] = $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 > :) > 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 assume >> only properties backed by storage will appear? (Yes, the array cast is >> still the simplest/most useful pure API to inspect object state 😁) >> > > 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.) > 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/
