[RFC] Property accessors

I haven't read it properly yet (been watching a little), but I just wanted to say thanks for the refreshing honesty :) Cheers Joe On Tue, 4 May 2021 at 12:34, Nikita Popov <nikita.ppv@gmail.com> wrote:

Hey NikiC, On Tue, May 4, 2021, 12:34 Nikita Popov <nikita.ppv@gmail.com> wrote:

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!

2021-05-04 12:33 GMT+02:00, Nikita Popov <nikita.ppv@gmail.com>:

Hi, In general I'm no fan of trivial getters and setters at all in OOP. I think a better solution is provided by: * readonly properties (or write-once, in the constructor) * namespace- or package-internal accessing; "internal" as an alternative to public/private Especially when getters and setters do not upheld any particular invariants or check validation. Note that namespace-internal access cannot be provided by getters and setters (though technically it's a big and hard change to PHP, AFAIK). Olle

On Tue, May 4, 2021, at 5:33 AM, Nikita Popov wrote:

This is an amazingly detailed RFC, and I love most of it. Thank you, Nikita! Regarding complexity, can you elaborate on what the most complex/tricky/problematic parts are? I'm mainly wondering if there are any parts that could be changed/slightly scaled back that would reduce the complexity more than it reduces capability. (Eg, removing guard and lazy for now is a good call, IMO, since both can be emulated with the other two.) All else equal, though, I would favor including all of it. I would say that the visibility controls get us 70% of the benefit, not 80/90%, but I do agree that those are hugely beneficial in and of themselves. *IF* you decide to scale it back, I would strongly recommend simply dropping the explicit accessors support and leaving the rest of the syntax the same. That way we know it's forward-compatible should we decide in the future to re-introduce explicit accessors. Some other questions: 1. Do setters have arbitrary access to the object? Can they read/set arbitrary other values? I'm thinking of something like this: class Person { private string $firstName; private string $lastName; private string $nickname; private int $age; public string $fullName { get { return "$this->firstName $this->lastName"; } set($fullName) { if ($this->age > 50) throw new Exception('You are too old to change your name.'); [$this->firstName, $this->lastName] = explode(' ', $fullName); $this->nickname = substr(0, 5, $this->firstName); } } } (A contrived example, obviously.) 2. My knee-jerk thought is to agree with Marco and avoid references entirely, for the sake of everyone's sanity. However, it is implied that &get is the only way to properly handle array property accessors. Am I understanding that correctly? If not, can you expand on array handling? I'd happily jettison references if arrays can still be supported nicely without them. 3. The partial incompatibility with constructor promotion is understandable, but disappointing. Is it at all possible to modify the promotion logic such that if a property is already defined with accessors, you can still promote it without a syntax error? I am thinking of this case: class Test { private int _$foo; public int $foo { get { return $this->_foo; } set ($foo) { if ($foo < 0) throw new InvalidArgumentException('Must be positive.'); $this->_foo = $foo; } } public function __construct(public int $foo) {} } (Though a guard would be nicer, as it avoids the second variable, but there are other considerations there.) 4. I still don't love $value being a magic name in setters. Being able to specify it explicitly is nice, and I would probably always use that myself (and push for it in coding standards), but would it be feasible to default it instead to the name of the variable? Since that variable name cannot be a backing variable, we know that it won't conflict with anything, but it would be more self-documenting. Thanks again, and I do hope you can be convinced all this effort is worth bringing to a vote. :-) --Larry Garfield

2021-05-04 12:33 GMT+02:00, Nikita Popov <nikita.ppv@gmail.com>:

Is this a typo? get() {} // Must not have parameter list But there are no parameters...? Olle

On 04-05-2021 12:33, Nikita Popov wrote:

Wow. Thanks for all the effort you put into this!

I think property accessors could be a huge enhancement to the language and may significantly change the look of PHP code in the long run. To fully appreciate what property accessors could do to PHP it may be useful to compare PHP to other languages that already have property accessors. In my case, I use both PHP and Python. By comparing how I use these two languages I can attempt to project how property accessors may change the way I use PHP. When I compare how I design APIs in PHP and Python, I expect to be exposing more public properties and fewer class methods. That will result in less library code. When I compare how I use APIs in PHP versus Python, I expect to be doing more direct property accessing and less method calling. That will make code look less cluttered in general. The complexity may very well be worth it when fully considering the impact it could have on how the language is used. Regards, Dik Takken

On Tue, 4 May 2021 at 06:34, Nikita Popov <nikita.ppv@gmail.com> wrote:

I don't have a vote, but I've worked on a few ActiveRecord-style ORMs in PHP, and this is the sort of feature that would make me want to rewrite everything to take advantage of it. I've used property accessors in C# and really appreciated them. The 20% increase in performance over magic getters and setters is a nice bonus. Allowing the creation of engine-enforced private-set properties is another bonus, even though I'm already able to enforce that in my projects via static analysis. Best wishes, Matt

On Tue, May 4, 2021, at 5:33 AM, Nikita Popov wrote:

Another question: I skimmed through the PR and its tests, and I didn't see any tests around attributes. How do you envision attributes interacting with accessor-using properties? I suppose there's no change for implicit accessors, but what happens for explicit accessors? --Larry Garfield

This is an amazingly comprehensive proposal and I commend you for all the effort.

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.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, May 4th, 2021 at 6:33 AM, Nikita Popov nikita.ppv@gmail.com wrote:

Hi, Thank you for the effort put forth in this RFC. I have a few questions after having read it. Will these properties work with the property_exists() function? I don't see it mentioned in the RFC, and seeing as how the function does not work with properties defined in __get() and __set(), the answer to this isn't obvious to me. The RFC also mentions that calling isset() on a write-only property will throw an Error exception. Should a new function along the lines of property_is_readable(), which returns true if the property is readable in the current scope, (and possibly its mirror function property_is_writable()) be introduced? Going through the Reflection API feels overly verbose and error prone to find out if a property is readable/writable. - Trevor