Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113606
MIME-Version: 1.0
References: <CAF+90c-HY-0fx+pTmntRJZKcQcZFfk3uJwrZ6FAMAx5_Wj+JHw@mail.gmail.com>
 <CAAwdEzApyQd52RpJ-gW+pNtBA=jA1bn74c-K1djcztRRgaYAag@mail.gmail.com>
 <CAF+90c8YMpGNLKehfFW6gWJx0mGUVqL0Rx+U262gGRP6cTXBgw@mail.gmail.com> <CAAwdEzDwD5sc6AQxLSnj0Dx=4ZsP1h0K83TS+jyN1x5_X7NAAg@mail.gmail.com>
In-Reply-To: <CAAwdEzDwD5sc6AQxLSnj0Dx=4ZsP1h0K83TS+jyN1x5_X7NAAg@mail.gmail.com>
Date: Fri, 19 Mar 2021 12:22:42 +0100
Message-ID: <CAF+90c9_=GkKbErf-z464_zqAHCDERbdLjd_uyoNvC9PERxoxQ@mail.gmail.com>
To: =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= <drealecs@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000346d9205bde1f05b"
Subject: Re: [PHP-DEV] [RFC] New in initializers
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000346d9205bde1f05b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 3, 2021 at 7:04 PM Alexandru P=C4=83tr=C4=83nescu <drealecs@gma=
il.com>
wrote:

>
> On Wed, Mar 3, 2021 at 5:49 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> On Wed, Mar 3, 2021 at 4:28 PM Alexandru P=C4=83tr=C4=83nescu <drealecs@=
gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> This looks very nice and I'm interested in further steps where not only
>>> new can be used :).
>>>
>>> The only thing I think it would be good to improve is to have a
>>> deterministic order for running initialization.
>>> Yes, this can be done at a later point, I guess. But maybe there is
>>> already an order of initialization right now and people would start
>>> replying on it and it would be good to mention it.
>>> Or maybe I didn't understand what this refers to: "this is not
>>> guaranteed behavior, and code should not rely on a specific point of
>>> evaluation."
>>>
>>
>> Which particular cases would you like to see specified? There are five
>> cases that have clearly defined behavior, and that I could explicitly
>> specify if desired:
>>
>>  * Non-class constants: Are evaluated immediately when declared (i.e.
>> when control flow reaches the declaration).
>>  * Attribute arguments: Are evaluated in the order of the arguments.
>>  * Parameter defaults: Are evaluated in the order of the parameters.
>>  * Non-static property defaults: Are evaluated in order of declaration,
>> with parent properties first. The constructor is run after defaults are
>> evaluated.
>>  * Static variables: Are evaluated immediately when declared (i.e. when
>> control flow reaches the declaration).
>>
>> And then there are the two problematic cases: Class constants and static
>> properties. Currently, PHP evaluates these semi-lazily. All class consta=
nts
>> and static properties are evaluated at the same time, on first "use" of =
the
>> class. I would consider this to be something of an implementation detail=
.
>> That's what I meant by that sentence.
>>
>> Now, if we allow "new" expressions, then I could see an argument in favo=
r
>> of requiring class constant and static property initializers to be
>> evaluated eagerly, i.e. directly after the class has been declared. This
>> would be a (minor) backwards-compatibility break, because invalid
>> constant/property declarations would error out immediately, even if they
>> don't get used. However, I do think that this would be the most predicta=
ble
>> behavior once potentially side-effecting expressions are involved (we
>> already support side-effecting expressions right now, but less explicitl=
y).
>>
>>
> Yes, this is what I was thinking about, to have a clear stated order of
> initialization.
> Yes, I agree that class constants and static properties should be eagerly
> declared when class is declared.
>
> So the order would be:
> - constants and static variables, when reaching the statement that does
> the declaration
> - class constants and static property, when class is declared, in order o=
f
> their declaration in the class
> - instance property, when class is instantiated, in order of their
> declaration in the class, before construct
> - parameter defaults and attribute arguments defaults, when
> function/method/attribute construct is called, in order of the declared
> parameter/arguments.
>
> That sounds good to me.
> Thanks!
>  Alex
>

I've updated the RFC (and implementation) to evaluate class constants and
static properties at time of class declaration. As such, everything should
have a well-defined evaluation order now.

However, this also means that this RFC now also contains a
backwards-compatibility break: Anything used inside class constant / static
property initializers needs to actually be available at the time the class
is declared. You can't first declare the class, then declare some
additional constants it uses, and then use it.

Nikita

--000000000000346d9205bde1f05b--