[RFC] Property write visibility

On Mon, Jun 29, 2020 at 12:42 PM André Rømcke <andre.romcke@gmail.com> wrote:

I agree that there is a use case for it, however I don't think the proposed syntax `public:private` is intuitive. Maybe we can come up with something better?

On 29/06/2020 10:41, André Rømcke wrote:

I'd like this feature as a stop-gap for accessors. However, I don't like the syntax at all, I couldn't reasonably vote for it in its current suggested state. I think it's just too messy. I'm not sure what the alternative should be though. It seems like the accessor syntax would be the only long-term clean way. Mark Randall

Hey André, This does indeed seem to cut into the traditional property accessors scope. I'm no longer seeing a reason to have property accessors, since immutable state (and promotion thereof) is much more relevant to fight bugs and improve application performance and maintainability. Therefore, I would endorse re-visiting the RFC at https://wiki.php.net/rfc/write_once_properties instead. Máté also linked today ( https://twitter.com/kocsismate90/status/1277625002720968704) that C# 9.0 is getting init-only properties, which looks similar to the RFC linked above. Assuming we solve annoyances around cloning, that would be a more sensible way forward, while property accessors seem to perpetuate the bad practice of getters and setters, which are the main cause for me having to fire up a debugger in any environment. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Mon, Jun 29, 2020 at 11:42 AM André Rømcke <andre.romcke@gmail.com> wrote:

Thanks, André, I really like it. I feel like it perfectly fits the runtime visibility model of PHP. The RFC could have some words to tell how this would behave when considering the existing magic accessors. We should also define the behavior when creating a reference (write access should be granted, isn't it?) and when unsetting a property. I'd like to share three more points to the discussion: 1. The previous RFC(s) shocked on a conflict between purity declarations (immutable/readonly) and the effective need for mutability in e.g. cloning operations. My experience in PHP is that keywords are strong guidelines but should never be hard blockers: PHP is a runtime scripting language and some of its power and flexibility comes from that, e.g. being able to use reflection sometime to read/write a property in a "friend" scope. "final" is the canonical contra-example of an imperative keyword that blocks legit use cases (e.g. inheritance proxies) I understand why some ppl want immutable/readonly hard guarantees. I think those are nice goals, and I also think that they are better solved by attributes/annotations. These features fit compiled languages. In PHP, they fit static analyzers. There are great ones already and they do a really good job. 2. In other answers, I'm seeing questions about private(isset)/private(unset) in addition to just read+write dissociation. I'm not sure this makes sense: once a property is declared, "isset-accessibility" is fully covered by "read-accessibility". Same for "unset-accessibility": it's included in "write-accessibility". Clarifying how magic accessors would work in the RFC should help solve this branch of the discussion. 3. About accessors, they look like another topic to me. I'm not seeing the need for accessors at all actually. You might disagree, but my point is: that's another topic. We don't need to agree on the usefulness of accessors to decide that this RFC provides actionable value that would benefit the ecosystem. Being able to enforce an externally-immutable-but-internally-mutable state is already a lot of value, I know where I would leverage it immediately. About the syntax, the proposed one looks quite effective to me. It's new, we need to get used to it. This should come fast given how simple it is. TL;DR, I fully support the RFC :) Nicolas

On 29-06-2020 11:41, André Rømcke wrote:

Perhaps another option could be to use attributes: <<ReadOnly>> public int $id; Assuming named arguments get accepted as well, we could use optional arguments to specify special behavior by writing: <<ReadOnly(protected: True)>> public int $id; These optional arguments could also be introduced later using a followup RFC, after introducing a basic ReadOnly attribute. This attribute-based approach could be extended later to implement property accessors. That would provide property accessors similar to how it is done in Python: <<Property>> public function someValue(): int { return $this->someValue; } which could then be accessed as: $instance->someValue The above accessor method would be the equivalent of: <<ReadOnly>> public int $someValue; That makes the ReadOnly attribute a short hand for the Property attribute. This short hand is something that Python does not have, by the way. Using accessor attributes to create a writable property could look like this: <<PropertySetter>> public function someValue(int $newValue) { $this->someValue = $newValue; } Making the property writable only in the protected or private scope could be done by using the existing mechanism of declaring the accessor method as protected or private. So perhaps an attribute-based approach provides a nice alternative path for gradually improving object ergonomics. Regards, Dik Takken

I do agree with Marco that this is a step in a wrong direction. Our goal should be not ensuring that a prop is not rewritten outside, but rather that it is not re-written at all. It makes no sense to rewrite a property in majority of cases: 1. fields of an DTO - nay. Should be immutable instead. You never change DTO, don't you? 2. injected services (like DB connection or an HTTP client) - nay. Shouldn't ever be overwritten once an object containing them is instantiated. Write-once / immutable is preferred. 3. data fields of an Entity-like object - looks like the only reasonable case. However adding dedicated syntax for this is arguably not much better that what we have now. It is already solvable with standard getX() pattern, or with a single method returning a required chunk of state as DTO. So for me this does only solve the problem of having getters (or dedicated methods) in #3, which is rare enough compared to other code, and is already solvable with syntax existing nowadays already. Introducing the new syntax, however, will have the following downsides: - adding proper immutable / write-once properties to the language will be met with much more resistance: "Why adding immutable if we have private set already!" - this will encourage using them in places where immutability (e.g. via static analysis tool like Psalm) should be used instead (see #1 and #2). - adding more advanced property accessors feature will be also likely met with more resistance.

On Mon, Jun 29, 2020 at 11:43 AM André Rømcke <andre.romcke@gmail.com> wrote:

I think this is a good direction to explore, but would recommend delaying it until PHP 8.1. As the RFC and discussion note, the design space here overlaps significantly with both readonly/immutability and property accessors. We should take enough time to consider these alternatives/extensions as well, to ensure that we don't end up with multiple distinct and possibly incompatible mechanisms. We don't have that time before PHP 8.0 feature freeze. Regards, Nikita

On Mon, 29 Jun 2020 at 10:42, André Rømcke <andre.romcke@gmail.com> wrote:

From the RFC: "Attempting to pass a property value outside of allowed writable scope as a reference, results in an error." This part could probably do with having some details for it. Also, any implementation of that rule might need to be checked for performance issues. cheers Dan Ack