On Tue, Apr 9, 2024, at 4:07 PM, Levi Morrison wrote: > I was playing around with 3v4l.org. Is the implementation up-to-date there? > > I don't have any hard objections at the moment, but after playing with > it for a while, I do kind of wonder if it's a lot of complexity for > what is effectively a niche feature because: > > 1. It does not support asymmetric visibility for get/set. Having a > public getter and private setter seems really natural.
Aviz is a separate RFC, for reasons we've covered before: They're actually two separate features that do not depend on each other, so we split them up to help reduce RFC size (something RFC authors are often encouraged to do). The Aviz RFC was put to a vote last year but didn't pass. If hooks pass, we do want to revisit aviz and bring it to another vote, as the argument may be stronger now with hooks in place. > 2. You can't access accessors for "siblings". If a use case for this is found, that should be addable in a future RFC with no notable BC break. (Assuming a syntax of self::$otherProp::get() or similar, it would only have the same slight edge case as the parent::$thisProp::get() has, as documented in the RFC. As we've decided that is too edge-casey to care about here, presumably the same would hold true for such an follow-up.) > 3. You can't do by-reference set (important for arrays). This is due to logical limitations in the context. By-ref set means set hooks don't get called. So we can either block by-ref manipulation when a set hook is defined, or we can make set hooks easily-bypassable suggestions at best. We have not found any way around that decision. (And as noted in the RFC, this problem is already present if just using methods. It's not a new issue.) Please note that *the scope of what is blocked has been reduced considerably from earlier versions of the RFC!* The only invalid combination is &get/set on a backed property, because of the issue above. Writing to an array returned from a hook is allowed in certain circumstances, namely, if it was returned by &get and there is no set. So we're only preventing the narrowest set of operations we reasonably can, without hamstringing the concept of a set hook in the first place, and we don't believe there is any logical approach that would allow more. If in the future someone can come up with an approach that would work, it would likely be addable in a BC way. > 4. You can't satisfy a parent's readonly property with a getter in a child. In the last week or two we've figured out a situation where we may be able to allow this; iff the child getter works by reading the parent's value, then it would *probably* still be able to satisfy readonly's guarantees. We haven't tried implementing it yet as the RFC is large enough as is, but it's possible that could be added in the future. The main issue is that there's no way to fully guarantee that a get hook on a readonly property is idemopotent, the way a bare readonly property is. (It's not a lack of desire to support it, just the logical issues in ensuring different features' invariants are maintained.) Note that it's still unclear what set from a child set hook should do, given that readonly properties are also silently private-set, even if the property itself is protected or public. Potentially we could mandate that a child set MUST use parent::$prop::set(), so the actual write is technically in the parent class. I've noted this before as a design flaw in readonly that really needs to be corrected, but that's not a job for this RFC. (We actually had a solution in the aviz RFC, but people pushed back on it so we had to remove it.) > Now, points 2 through 4 are fairly minor and niche by themselves, but > if we take all these restrictions as a whole... I'm a bit worried. Hopefully the above comments make you less worried. :-) --Larry Garfield
