Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120368
MIME-Version: 1.0
References: <641b1ca0-d33f-4f38-ae64-81b4abce24da@app.fastmail.com> <6b1fe5c4-fa92-42c0-b388-32cdda0a27a2@app.fastmail.com>
In-Reply-To: <6b1fe5c4-fa92-42c0-b388-32cdda0a27a2@app.fastmail.com>
Date: Sat, 20 May 2023 09:04:47 -0300
Message-ID: <CAGS0MVBBpK3v-=Lsq8nSTrYXY5MjUkg-HP4OjXwSUtRyX_qgJg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003b07ab05fc1eda94"
Subject: Re: [PHP-DEV] [RFC] Property hooks, nee accessors
From: ericklima.comp@gmail.com (Erick de Azevedo Lima)

--0000000000003b07ab05fc1eda94
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I can't wait!

Especially because I'm heading a modernization of the systems in my
organization and my plan is to use the cutting edge PHP version for it.
Currently our internal "framework" uses PHP 7.4, but with a PHP 5.6 coding
style.
Again: I can't wait!

I can't do much but thank everyone who spends their time to make PHP evolve=
.
Thank you all!

Regards,
Erick

Em sex., 19 de mai. de 2023 =C3=A0s 17:48, Larry Garfield <larry@garfieldte=
ch.com>
escreveu:

> On Mon, May 8, 2023, at 9:38 PM, Larry Garfield wrote:
> > 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 folks.  Based on feedback we've made a few smaller changes to the RFC.
>
> Changelog:
>
> * The sections describing isset/unset and magic methods have been
> rewritten to be clearer.  Nothing changed in the actual behavior, it is n=
ow
> just explained better.
>
> * Contravariance on the "set" type is now enforced.  Ilija figured out ho=
w
> to make it work. :-)  That means a non-contravariant type on the set hook
> will now throw an error, as expected.
>
> * After extensive discussion with Nicolas Grekas, we've decided to allow
> references in a very narrow case.  Specifically, on a *virtual property*
> (one that has no inherent backing store), you may implement a `&get` hook
> instead of `get`, and the value it returns will be returned by reference,
> and may be captured using $foo =3D& $bar->baz;  We determined that it is =
a
> bit better for BC (in the rare cases that you actually want to get a
> reference to a property, you can, even if it requires a little more work)=
,
> doesn't break anything else, and is consistent with the way `&__get`
> behaves.  __get/__set are basically "anonymous virtual properties", so no=
w
> they behave the same way.  By the same token, setting by reference is sti=
ll
> not allowed, which is also true for __set today.
>
> As there was no other interest in it stated, we're going to hold off on a=
n
> `unset` hook at this time.  Given the earlier discussion I think there is=
 a
> valid use case for it, so it would be a worthwhile follow up RFC in the
> future, but for the moment we want to keep it simple.
>
> There also doesn't seem to be much interest in specifying which hook gets
> the double-shortened syntax.  I can see the argument for it, but it would
> increase the typing in a common case for an unclear benefit, and only one
> person expressed any interest in it.  So we're not going to go that route=
.
>
> There's two items still pending.
>
> 1. Ilija is experimenting with the `parent::$prop::get()` syntax, to see
> if either the syntax or implementation can be simplified.  There may or m=
ay
> not be a small change here as a result, TBD.
>
> 2. Ilija still has to verify that foreach() can work with virtual
> properties as the RFC currently describes.  The implementation details ar=
e
> thornier than they seem, so that still needs some validation and testing.
>
> Assuming both of those get sorted out soon, we will probably call a vote
> around the end of the month, give or take.
>
> Cheers.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--0000000000003b07ab05fc1eda94--