Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121775
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
In-Reply-To: <EFC20C43-EFD2-44F0-B4A9-47AA7E6D8824@gmail.com>
Date: Thu, 23 Nov 2023 10:41:56 +0100
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <A1D279AF-BE2C-4E36-B9D6-06DEC2F08DA0@gmail.com>
References: <DB0E3270-34F3-4248-8B11-2852AC63A595@gmail.com>
 <C2C5C432-B65A-4669-92C5-33A7FD72030B@gmail.com>
 <EFC20C43-EFD2-44F0-B4A9-47AA7E6D8824@gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] Harmonise "untyped" and "typed"
 properties
From: claude.pache@gmail.com (Claude Pache)



> Le 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.com> wrote:
>> What you describe in the last sentence is what was initially designed =
and implemented by the RFC: https://wiki.php.net/rfc/typed_properties_v2 =
(section Overloaded Properties).
>>=20
>> However, it was later changed to the current semantics (unset() =
needed in order to trigger __get()) in =
https://github.com/php/php-src/pull/4974
>=20
>=20
> 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 =
unfortunate.
>=20
> 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 solution is =
to assign a valid value to the property. And making the behaviour =
different 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.
>=20
> But I guess I'm 4 years too late to make that case.
>=20

Hi,=20

I think that the legitimacy of the current behaviour is not something to =
be convinced by abstract reasoning like we are doing now (otherwise, it =
wouldn=E2=80=99t probably have waited a live release to be implemented =
in a rush), but something that can be understood only by considering the =
conflicting uses of  __get(), which leads to conflicting expectations, =
and how they managed to live together despite a fundamental =
contradiction:

1. __get() is used to implement virtual properties (as mentioned in the =
linked bug report). For this use case, access to a declared property =
should not call __get() (whose implementation may be hidden away in a =
superclass).

2. __get() is used to implement lazy properties. For this use case, =
access to an uninitialised (or unset, or undeclared) property should =
call __get().

The two expectations did live together as long as declared properties =
were also initialised (implicitly, to null). It is true that they are =
formally incompatible; when you say:

> And making the behaviour different 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.

you are referring to the expectation given by use case 1, which =
contradicts the expectation given by use case 2. However, it is not a =
problem in practice, because users of classes implementing (1) but not =
(2) do not unset declared properties, ever.

The conflict became evident with the advent of typed properties, which =
cannot be implicitly initialised to null in general. As both use cases =
are firmly rooted in practice, both should be taken in account. The =
current, cumbersome and unfortunate behaviour allows to keep sane =
semantics for those classes using bad practices (use case 1), while not =
invalidating naughty hacks used by other classes (use case 2).


=E2=80=94Claude