On Tue, Apr 9, 2024 at 8:56 PM Larry Garfield <la...@garfieldtech.com> wrote: > > 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
Off-topic random thought: > The Aviz RFC was put to a vote last year but didn't pass. It would be really nice if votes weren't just a yes/no vote, but yes/needs-more-work/no vote, where needs-more-work and no are effectively the same in terms of passing the RFC, but needs-more-work just means there is more to do (either addressing ugly syntax or the idea is sound, but as it says, it needs more work), and can thus be simply revoted on after concerns are addressed -- instead of creating a whole new RFC that needs to pass the "not too similar to other RFCs rule." I got the impression from the Aviz discussions that most people were against Aviz due to the syntax, not the feature itself. It would be absolutely tragic if this failed to pass simply because people expected Aviz here. Robert Landers Software Engineer Utrecht NL
