[prev in list] [next in list] [prev in thread] [next in thread] 

List:       php-internals
Subject:    Re: [PHP-DEV] [RFC] Property hooks, nee accessors
From:       "Larry Garfield" <larry () garfieldtech ! com>
Date:       2023-05-30 17:14:53
Message-ID: 331a26ff-a11f-4a7e-b75b-5d588069aa5a () app ! fastmail ! com
[Download RAW message or body]



-- 
  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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php


[prev in list] [next in list] [prev in thread] [next in thread]