Re: [RFC] Property hooks, nee accessors
| From: | Larry Garfield | Date: | Tue, 30 May 2023 17:14:53 +0000 |
| Subject: | Re: [RFC] Property hooks, nee accessors | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120472@lists.php.net to get a copy of this message | ||
--
Larry Garfield
larry@garfieldtech.com
On Mon, May 29, 2023, at 8:28 PM, Claude Pache wrote:
>> Le 8 mai 2023 à 23:38, Larry Garfield <larry@garfieldtech.com> a écrit :
>>
>> Ilija Tovilo and I would like to offer another RFC for your consideration. It's been
a while in coming, and we've evolved the design quite a bit just in the last week so if you saw
an earlier draft of it in the past few months, I would encourage you to read it over again to make
sure we're all on the same page. I'm actually pretty happy with where it ended up, even
if it's not the original design. This approach eliminates several hard-to-implement edge cases
while still providing a lot of functionality in one package.
>>
>> https://wiki.php.net/rfc/property-hooks
>>
>
> Hi,
>
> If I understand correctly, given:
>
> <?php
>
> class C {
>
> public int $someInt;
>
> public float $someFloat;
>
> public int $someIntWithHook {
> get => $field;
> set => $field = $value;
> }
>
> public float $someFloatWithHook {
> get => $field;
> set => $field = $value;
> }
>
> }
> ?>
>
> we have:
>
> <?php
> $obj = new C;
> var_dump($obj->someInt = 42.0); // int(42)
> var_dump($obj->someFloat = 42); // float(42)
> ?>
>
> but:
>
> <?php
> $obj = new C;
> var_dump($obj->someIntWithHook = 42.0); // float(42)
> var_dump($obj->someFloatWithHook = 42); // int(42)
> ?>
>
> If I am correct, it means that the “This also implies that adding a set
> hook to a property cannot change the result of the = operator”
> statement is a bit too optimistic.
We looked into this a bit; it's correct if you're in weak mode. In strict mode, it
applies only to $o->float = $anInt, as that's the only legal type coercion. Still,
you're right that it's not quite "cannot change", so I've adjusted the
wording to better describe the edge cases. The behavior is still the same as __set(), so we
don't see a need to change it further.
Thanks for the catch.
--Larry Garfield