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 :) * 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.) * 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)? Regards, Nikita
