Re: [RFC[ Property accessor hooks, take 2

On 15 March 2024 17:11:29 GMT, Larry Garfield <larry@garfieldtech.com> wrote: >On Wed, Mar 13, 2024, at 10:26 PM, Rowan Tommins [IMSoP] wrote: >> 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. Unless I'm misunderstanding something, the backing field in Kotlin is accessible only inside the hooks, nowhere else. I don't know what would happen if a hook caused a recursive call to itself, but there's no mention in the docs of it bypassing the hooks, only this: > This backing field can be referenced in the accessors using the > field identifier and > The field identifier can only be used in the accessors of the > property. And then a section explaining that more complex hooks should use a separate backing property - which is the only option in C#, and roughly what people would do in PHP today with __get and __set. Kotlin does have a special syntax for "delegating" hooks, but looking at the examples, they do not use the backing field at all, they have to provide their own storage. >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. I understand that *something* needs to happen if a recursive call happens, but it could just be an error, like any other unbounded recursion. I can also understand the temptation to make it something more useful than an error, and provide a way to access the "backing field" / "raw value" from outside the hook. But it does lead to something quite surprising: the same line of code does different things depending on how it is called. I doubt many people have ever discovered that __get and __set work that way, since as far as I can see it's only possible to use deliberately if you're dynamically adding and unsetting properties inside your class. So, I don't necessarily think hooks working that way is the wrong decision, I just think it's a decision we should make consciously, not one that's obvious. Regards, Rowan Tommins [IMSoP]