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. * 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 😁) * 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! >
