On Wed, Mar 13, 2024, at 10:26 PM, Rowan Tommins [IMSoP] wrote: > On 12/03/2024 22:43, Larry Garfield wrote: >> It's slightly different, yes. The point is that the special behavior of a >> hook is disabled if you are within the call stack of a hook, just like the >> special behavior of __get/__set is disabled if you are within the call stack >> of __get/__set. What happens when you hit an operation that would otherwise >> go into an infinite loop is a bit different, but the "disable to avoid an >> infinite loop" logic is the same. > > > I guess I'm looking at it more from the user's point of view: it's very > rare with __get and __set to have a method that sometimes accesses the > "real" property, and sometimes goes through the "hook". Either there is > no real property, or the property has private/protected scope, so any > method on the classes sees the "real" property *regardless* of access > via the hook. > > I think it would be more helpful to justify this design on its own > merits, particularly because it's a significant difference from other > languages (which either don't have a "real property" behind the hooks, > or in Kotlin's case allow access to it only *directly* inside the hook > definitions, via the "field" keyword).
I'm not sure I follow. The behavior we have currently is very close to how Kotlin works, from a user perspective. (The internal implementation is backwards from Kotlin, but that doesn't matter to the user.) I've lost track of which specific issue you have an issue with or would want changed. The guards to prevent an infinite loop are necessary, for the same reasons as they are necessary for __get/__set. We couldn't use a backing field otherwise, without some other syntax. (This is where Kotlin uses 'field'.) So, I'm not really sure what we're discussing at this point. What specific changes are you suggesting? >> With the change to allow &get in the absence of set, I believe that would >> already work. >> >> cf: https://3v4l.org/3Gnti/rfc#vrfc.property-hooks > > > Awesome! The RFC should probably highlight this, as it gives a > significant extra option for array properties. Updated. I may try to rewrite the array and references section this weekend, as with the changes in the design to be more permissive I'm not sure it's entirely clear anymore what the net result is. --Larry Garfield
