Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113353
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>
In-Reply-To: <CAF+90c8YMpGNLKehfFW6gWJx0mGUVqL0Rx+U262gGRP6cTXBgw@mail.gmail.com>
Date: Wed, 3 Mar 2021 20:04:28 +0200
Message-ID: <CAAwdEzDwD5sc6AQxLSnj0Dx=4ZsP1h0K83TS+jyN1x5_X7NAAg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009b8b8e05bca5aff0"
Subject: Re: [PHP-DEV] [RFC] New in initializers
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--0000000000009b8b8e05bca5aff0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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@g=
mail.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 guarantee=
d
>> 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. whe=
n
> 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 constan=
ts
> and static properties are evaluated at the same time, on first "use" of t=
he
> 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 favor
> 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 predictab=
le
> behavior once potentially side-effecting expressions are involved (we
> already support side-effecting expressions right now, but less explicitly=
).
>
>
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 of
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

--0000000000009b8b8e05bca5aff0--