> On May 4, 2021, at 6:33 AM, 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.
This is an amazingly comprehensive proposal and I commend you for all the effort.
> 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.
Adding property accessors to PHP could significantly improve robustness in userland code. The KEY
benefit is how userland classes could evolve in complexity as required *without* breaking a
classes' API. That benefit cannot be overstated IMO.
If this proposal needs to change, I hope you continue to ensure it can provide zero breakage during
evolution of userland code.
-Mike
P.S. I also concur with Larry Garfield and am uncomfortable with the magic $value
variable. I would prefer to always be explicitly specified in parens on — e.g.
set($var) — if it needs to be used in the RHS of an assignment inside the set block.
But this is a trivial concern compared to the KEY benefit mentioned above.