Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115896
MIME-Version: 1.0
References: <CAF+90c9_qu=PiTS81J2mesPfJdz7n5nSi3qoLNLjhEGN-aTytA@mail.gmail.com>
 <20210830141342.2077bcfb@mcmic-probook.opensides.be>
In-Reply-To: <20210830141342.2077bcfb@mcmic-probook.opensides.be>
Date: Mon, 30 Aug 2021 14:37:21 +0200
Message-ID: <CAF+90c-Ukx1AvTjccfwWtdWXcvfnQHFzPfFA-z3OaRpgpzUg6Q@mail.gmail.com>
To: =?UTF-8?Q?C=C3=B4me_Chilliet?= <come.chilliet@fusiondirectory.org>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002b989b05cac619c1"
Subject: Re: [PHP-DEV] [RFC] Deprecate dynamic properties
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000002b989b05cac619c1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 30, 2021 at 2:14 PM C=C3=B4me Chilliet <
come.chilliet@fusiondirectory.org> wrote:

> Le Wed, 25 Aug 2021 12:02:49 +0200,
> Nikita Popov <nikita.ppv@gmail.com> a =C3=A9crit :
> > Hi internals,
> >
> > I'd like to propose the deprecation of "dynamic properties", that is
> > properties that have not been declared in the class (stdClass and
> > __get/__set excluded, of course):
> >
> > https://wiki.php.net/rfc/deprecate_dynamic_properties
>
> If I understand correctly the RFC, in these two classes:
>
> class A {
>     public $prop;
>
>     public function __construct() {
>         unset($this->prop);
>     }
> }
>
> class B {
>     public $prop;
> }
>
> The property $prop is not in the same state in the end? What is the
> difference?
> isset returns FALSE for both, no? And property_exists?
>

In the latter case, the property has value null. In the former case, it is
unset. In both cases, it is declared. Accessing an unset property will
trigger __get/__set. Accessing a null property will not (assuming it is
visible).

Is it something that was the same before the RFC and would be different
> after,
> or is it already two different cases and how?


This RFC does not have any impact on this behavior. This is a "standard"
pattern used for lazy initialization.

Regards,
Nikita

--0000000000002b989b05cac619c1--