Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121774
Feedback-ID: id4a9467a:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1234-gac66594aae-fm-20231122.001-gac66594a
MIME-Version: 1.0
Message-ID: <eec44d80-e92e-43a1-8e4e-80339a8aba34@app.fastmail.com>
In-Reply-To: 
 <CAOWwgpmamUd6EPxqkDinLo3t3CGE_H6gCYjFRSKMV+x2_Hj26g@mail.gmail.com>
References: <DB0E3270-34F3-4248-8B11-2852AC63A595@gmail.com>
 <C2C5C432-B65A-4669-92C5-33A7FD72030B@gmail.com>
 <EFC20C43-EFD2-44F0-B4A9-47AA7E6D8824@gmail.com>
 <CAOWwgpmamUd6EPxqkDinLo3t3CGE_H6gCYjFRSKMV+x2_Hj26g@mail.gmail.com>
Date: Thu, 23 Nov 2023 10:28:13 +0100
To: "Nicolas Grekas" <nicolas.grekas+php@gmail.com>,
 "Rowan Tommins" <rowan.collins@gmail.com>
Cc: "Levi Morrison" <internals@lists.php.net>
Content-Type: multipart/alternative;
 boundary=c63e7c567ae648b8ae4a04a6c8d96c50
Subject: Re: [PHP-DEV] Re: [RFC][Discussion] Harmonise "untyped" and "typed" properties
From: nikita.ppv@gmail.com ("Nikita Popov")

--c63e7c567ae648b8ae4a04a6c8d96c50
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 23, 2023, at 09:48, Nicolas Grekas wrote:
> Hi Rowan,
>=20
> Le jeu. 23 nov. 2023 =C3=A0 08:56, Rowan Tommins <rowan.collins@gmail.=
com> a
> =C3=A9crit :
>=20
> > On 23 November 2023 01:37:06 GMT, Claude Pache <claude.pache@gmail.c=
om>
> > wrote:
> > >What you describe in the last sentence is what was initially design=
ed and
> > implemented by the RFC: https://wiki.php.net/rfc/typed_properties_v2
> > (section Overloaded Properties).
> > >
> > >However, it was later changed to the current semantics (unset() nee=
ded in
> > order to trigger __get()) in https://github.com/php/php-src/pull/4974
> >
> >
> > Good find. So not only is it not specified this way in the RFC, it
> > actually made it into a live release, then someone complained and we=
 rushed
> > out a more complicated version "to avoid WTF". That's really unfortu=
nate.
> >
> > I'm not at all convinced by the argument in the linked bug report -
> > whether you get an error or an unexpected call to __get, the solutio=
n is to
> > assign a valid value to the property. And making the behaviour diffe=
rent
> > after unset() just hides the user's problem, which is that they didn=
't
> > expect to *ever* have a call to __get for that property.
> >
> > But I guess I'm 4 years too late to make that case
> >
>=20
> Sorry this comes as a surprise to you but you're rewriting history her=
e.
> The current behavior, the one that was fixed in that commit, matches h=
ow
> PHP behaved before typed properties, so this commit brought consistenc=
y.
>=20
> About the behavior, it's been in use for many years to build lazy prox=
ies.
> I know two major use cases that leverage this powerful capability: Doc=
trine
> entities and Symfony lazy services. There are more as any code that
> leverages ocramius/proxy-manager relies on this.
>=20
> About the vocabulary, the source tells us that "uninitialized" propert=
ies
> that are unset() become "undefined". I know that's not super accurate =
since
> a typed property is always defined semantically, but that's nonetheles=
s the
> flag that is used in the source. Maybe this could help with the RFC.

This. The lazy initialization use case is the only reason why we still a=
llow declared properties to be unset at all.

Our long term plan was to find an alternative way to support lazy initia=
lization for properties, and then forbid calling unset() on declared pro=
perties. However, we still don't have that alternative today.

Regards,
Nikita

--c63e7c567ae648b8ae4a04a6c8d96c50--