On 15 March 2024 17:11:29 GMT, Larry Garfield <la...@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]
