> > I'd like to start discussion on a new RFC proposing a way to be able to > (optionally) specify property > write visibility, separate from read: > > https://wiki.php.net/rfc/property_write_visibility > > This enables readonly, write-only and immutable like semantics for PHP's > properties. > > These are the common use cases where users tend to resort to magic methods > or setter/getter > methods. This proposal will as such avoid unnecessary boilerplate, makes > coding easier and more > ergonomic, and in the case of magic method usage improve performance. >
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
