Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120722
MIME-Version: 1.0
References: <641b1ca0-d33f-4f38-ae64-81b4abce24da@app.fastmail.com>
 <51D1B70D-D77A-40A1-8AE5-534E13C67CBB@gmail.com> <331a26ff-a11f-4a7e-b75b-5d588069aa5a@app.fastmail.com>
In-Reply-To: <331a26ff-a11f-4a7e-b75b-5d588069aa5a@app.fastmail.com>
Date: Sat, 1 Jul 2023 16:17:38 -0300
Message-ID: <CAGS0MVDYTqzDVBHj1f66xryQf06t5-aXKKzcjegEFYQmPi+OPQ@mail.gmail.com>
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000087bfc805ff71cb8e"
Subject: Re: [PHP-DEV] [RFC] Property hooks, nee accessors
From: ericklima.comp@gmail.com (Erick de Azevedo Lima)

--00000000000087bfc805ff71cb8e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey everyone.

Any news on this? I'm really excited about this one. =3D)

--
Erick de Azevedo Lima

Em ter., 30 de mai. de 2023 =C3=A0s 14:15, Larry Garfield <larry@garfieldte=
ch.com>
escreveu:

>
>
> --
>   Larry Garfield
>   larry@garfieldtech.com
>
> On Mon, May 29, 2023, at 8:28 PM, Claude Pache wrote:
> >> Le 8 mai 2023 =C3=A0 23:38, Larry Garfield <larry@garfieldtech.com> a =
=C3=A9crit
> :
> >>
> >> 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 =3D> $field;
> >         set =3D> $field =3D $value;
> >     }
> >
> >     public float $someFloatWithHook {
> >         get =3D> $field;
> >         set =3D> $field =3D $value;
> >     }
> >
> > }
> > ?>
> >
> > we have:
> >
> > <?php
> > $obj =3D new C;
> > var_dump($obj->someInt =3D 42.0); // int(42)
> > var_dump($obj->someFloat =3D 42); // float(42)
> > ?>
> >
> > but:
> >
> > <?php
> > $obj =3D new C;
> > var_dump($obj->someIntWithHook =3D 42.0); // float(42)
> > var_dump($obj->someFloatWithHook =3D 42); // int(42)
> > ?>
> >
> > If I am correct, it means that the =E2=80=9CThis also implies that addi=
ng a set
> > hook to a property cannot change the result of the =3D operator=E2=80=
=9D
> > statement is a bit too optimistic.
>
> We looked into this a bit; it's correct if you're in weak mode.  In stric=
t
> mode, it applies only to $o->float =3D $anInt, as that's the only legal t=
ype
> 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
>
>

--00000000000087bfc805ff71cb8e--