Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113351
MIME-Version: 1.0
References: <CAF+90c-HY-0fx+pTmntRJZKcQcZFfk3uJwrZ6FAMAx5_Wj+JHw@mail.gmail.com>
 <CAAwdEzApyQd52RpJ-gW+pNtBA=jA1bn74c-K1djcztRRgaYAag@mail.gmail.com>
In-Reply-To: <CAAwdEzApyQd52RpJ-gW+pNtBA=jA1bn74c-K1djcztRRgaYAag@mail.gmail.com>
Date: Wed, 3 Mar 2021 16:49:39 +0100
Message-ID: <CAF+90c8YMpGNLKehfFW6gWJx0mGUVqL0Rx+U262gGRP6cTXBgw@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="0000000000006deaf305bca3cd97"
Subject: Re: [PHP-DEV] [RFC] New in initializers
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000006deaf305bca3cd97
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 3, 2021 at 4:28 PM Alexandru P=C4=83tr=C4=83nescu <drealecs@gma=
il.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 constants
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 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 predictable
behavior once potentially side-effecting expressions are involved (we
already support side-effecting expressions right now, but less explicitly).

Regards,
Nikita

Also, in
> https://wiki.php.net/rfc/new_in_initializers#evaluation_of_expressions
> I think that for the static initialization the text should say "are
> evaluated once." instead of "are evaluated once per request." so we are
> more general, including CLI cases.
>
> I'm used with dynamic initialization coming from other languages, learnin=
g
> it in Java 13-14 years ago, including the clearly defined order of
> initialization.
>
> Regards,
> Alex
>
>
>
> On Wed, Mar 3, 2021 at 5:04 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> Hi internals,
>>
>> I would like to propose allowing the use of "new" inside various
>> initializer expressions: https://wiki.php.net/rfc/new_in_initializers
>>
>> In particular, this allows specifying object default values for properti=
es
>> and parameters, and allows the use of objects as attribute arguments.
>>
>> The RFC is narrow in scope in that it only adds support for "new". An
>> extension to other call kinds should be straightforward though.
>>
>> Regards,
>> Nikita
>>
>

--0000000000006deaf305bca3cd97--