Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129784
Precedence: list
MIME-Version: 1.0
References: <1d5a3698-2796-4bc1-ac34-79b8dbc03e48@mabe.berlin>
In-Reply-To: <1d5a3698-2796-4bc1-ac34-79b8dbc03e48@mabe.berlin>
Date: Mon, 19 Jan 2026 01:33:24 +0700
Message-ID: <CANLbj-rqKNRLrm78BzwCu=eh5WtHatzPbFoUOYJf+Y=VjhKhog@mail.gmail.com>
Subject: Re: [PHP-DEV] Object support in class constants
To: "Marc B." <marc@mabe.berlin>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c75b830648add05c"
From: ayesh@php.watch (Ayesh Karunaratne)

--000000000000c75b830648add05c
Content-Type: text/plain; charset="UTF-8"

>
> Is there are a reason for this limitation especially since "new"
> expression is valid for argument default values as well?
>

From the RFC
https://wiki.php.net/rfc/new_in_initializers#unsupported_positions

> New expressions continue to not be supported in (static and non-static)
property initializers and class constant initializers. The reasons for this
are twofold:
>
> For non-static property initializers, the initializer expression needs to
be evaluated on each object creation. There are currently two places where
this could happen: As part of object creation, and as part of the
constructor call. Doing this as part of object creation can create issues
for unserialization and any other process that is based on
newInstanceWithoutConstructor() and does not want to implicitly execute
potential side-effects.
>
> Performing the initialization by injecting code in the constructor avoids
the issue, but requires that constructor to actually be called. In
particular, this would necessitate generating constructors for classes that
do not explicitly declare them, and the disciplined invocation of such
constructors from potential child constructors. The third option would be
to introduce an additional initialization phase between creation and
construction.
>
> For static property initializers and class constant initializers a
different evaluation order issue arises. Currently, these initializers are
evaluated lazily the first time a class is used in a certain way (e.g.
instantiated). Once initializers can contain potentially side-effecting
expressions, it would be preferable to have a more well-defined evaluation
order. However, the straightforward approach of evaluating initilizers when
the class is declared would break certain existing code patterns. In
particular, referencing a class that is declared later in the same file
would no longer work.
>
> As such support in these contexts is delayed until such a time as a
consensus on the preferred behavior can be reached.

--000000000000c75b830648add05c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>&gt;<br>&gt; Is there are a reason for this limitation=
 especially since &quot;new&quot;<br>&gt; expression is valid for argument =
default values as well?<br>&gt;<br><br>From the RFC <a href=3D"https://wiki=
.php.net/rfc/new_in_initializers#unsupported_positions">https://wiki.php.ne=
t/rfc/new_in_initializers#unsupported_positions</a><br><br>&gt; New express=
ions continue to not be supported in (static and non-static) property initi=
alizers and class constant initializers. The reasons for this are twofold:<=
br>&gt;=C2=A0<br>&gt; For non-static property initializers, the initializer=
 expression needs to be evaluated on each object creation. There are curren=
tly two places where this could happen: As part of object creation, and as =
part of the constructor call. Doing this as part of object creation can cre=
ate issues for unserialization and any other process that is based on newIn=
stanceWithoutConstructor() and does not want to implicitly execute potentia=
l side-effects.<br>&gt;=C2=A0<br>&gt; Performing the initialization by inje=
cting code in the constructor avoids the issue, but requires that construct=
or to actually be called. In particular, this would necessitate generating =
constructors for classes that do not explicitly declare them, and the disci=
plined invocation of such constructors from potential child constructors. T=
he third option would be to introduce an additional initialization phase be=
tween creation and construction.<br>&gt;=C2=A0<br>&gt; For static property =
initializers and class constant initializers a different evaluation order i=
ssue arises. Currently, these initializers are evaluated lazily the first t=
ime a class is used in a certain way (e.g. instantiated). Once initializers=
 can contain potentially side-effecting expressions, it would be preferable=
 to have a more well-defined evaluation order. However, the straightforward=
 approach of evaluating initilizers when the class is declared would break =
certain existing code patterns. In particular, referencing a class that is =
declared later in the same file would no longer work.<br>&gt;<br><div>&gt; =
As such support in these contexts is delayed until such a time as a consens=
us on the preferred behavior can be reached.</div><div><br></div></div>

--000000000000c75b830648add05c--