[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

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.

Regards,
Nikita

Hey NikiC,

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!

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

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.

Regards,
Nikita

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

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.

Regards,
Nikita

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:

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.

Regards,
Nikita

Is this a typo?

get() {} // Must not have parameter list

But there are no parameters...?

Olle

Hi internals,

I'd like to present an RFC for property accessors:
https://wiki.php.net/rfc/property_accessors

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

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.

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

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.

Regards,
Nikita

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

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.

Regards,
Nikita

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

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.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

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.

Regards,

Nikita

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