Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114900
Message-ID: <E4E24E19-C32E-4C21-A0F6-8BC83732EF76@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_9887F74C-19FE-4C63-B92A-8619ADA7163C"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Tue, 15 Jun 2021 23:46:03 -0400
In-Reply-To: <CAF+90c9EaGreC0y6FagwLn+2OSQUgcQe9UmQdzZaqEYGw0aJbQ@mail.gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
To: Nikita Popov <nikita.ppv@gmail.com>
References: <CAF+90c-HY-0fx+pTmntRJZKcQcZFfk3uJwrZ6FAMAx5_Wj+JHw@mail.gmail.com>
 <88588b8f-5729-4458-90b1-c602f751e128@www.fastmail.com>
 <CAF+90c9EaGreC0y6FagwLn+2OSQUgcQe9UmQdzZaqEYGw0aJbQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] New in initializers
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_9887F74C-19FE-4C63-B92A-8619ADA7163C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Jun 15, 2021, at 11:06 AM, Nikita Popov <nikita.ppv@gmail.com> =
wrote:
>=20
> On Fri, Jun 11, 2021 at 5:02 PM Larry Garfield <larry@garfieldtech.com =
<mailto:larry@garfieldtech.com>>
> wrote:
>=20
>> On Wed, Mar 3, 2021, at 9:03 AM, Nikita Popov wrote:
>>> Hi internals,
>>>=20
>>> I would like to propose allowing the use of "new" inside various
>>> initializer expressions: =
https://wiki.php.net/rfc/new_in_initializers
>>>=20
>>> In particular, this allows specifying object default values for
>> properties
>>> and parameters, and allows the use of objects as attribute =
arguments.
>>>=20
>>> The RFC is narrow in scope in that it only adds support for "new". =
An
>>> extension to other call kinds should be straightforward though.
>>>=20
>>> Regards,
>>> Nikita
>>=20
>> Hi Nikita.  What's the status of this RFC?  Are you going to bring it =
to a
>> vote, or is something else blocking it?
>>=20
>=20
> I've just pushed a larger update to the RFC, which limits the places =
where
> new is supported.
>=20
> Supported:
> * Parameter default values (includes promoted properties)
> * Attribute arguments
> * Static variable initializers
> * Global constant initializers
>=20
> Not supported:
> * Static and non-static property initializers
> * Class constant initializers

And I am saddened by the lack of class constant initializers.  That's =
the main use case I am interested in and I had been watching this RFC =
anxiously for that one reason. .  (In particular, because it would allow =
me to assign classes to constants with __ToString() methods to lazy load =
information.)

> I believe the cases that are now supported should be completely =
unambiguous
> and uncontroversial.

Well, at least it is the former.  :-)

-Mike


--Apple-Mail=_9887F74C-19FE-4C63-B92A-8619ADA7163C--