Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113348
MIME-Version: 1.0
References: <CAF+90c-HY-0fx+pTmntRJZKcQcZFfk3uJwrZ6FAMAx5_Wj+JHw@mail.gmail.com>
In-Reply-To: <CAF+90c-HY-0fx+pTmntRJZKcQcZFfk3uJwrZ6FAMAx5_Wj+JHw@mail.gmail.com>
Date: Wed, 3 Mar 2021 17:27:46 +0200
Message-ID: <CAAwdEzApyQd52RpJ-gW+pNtBA=jA1bn74c-K1djcztRRgaYAag@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000026755605bca37f98"
Subject: Re: [PHP-DEV] [RFC] New in initializers
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--00000000000026755605bca37f98
Content-Type: text/plain; charset="UTF-8"

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."

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, learning
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 properties
> 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
>

--00000000000026755605bca37f98--