Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123686
Precedence: bulk
MIME-Version: 1.0
References: <CAGS0MVC9q+byG_Gogt+kb84TSVKG-FV+5xM=vMTZWQ+nyi4g_g@mail.gmail.com>
In-Reply-To: <CAGS0MVC9q+byG_Gogt+kb84TSVKG-FV+5xM=vMTZWQ+nyi4g_g@mail.gmail.com>
Date: Wed, 19 Jun 2024 20:36:00 +0200
Message-ID: <CAPyj-LC6k+w9CnTjLn_4js8tTTPd1wY2Pu6F54NMQbc2RcRxhA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Static Constructor
To: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Erick

On Wed, Jun 19, 2024 at 2:34=E2=80=AFPM Erick de Azevedo Lima
<ericklima.comp@gmail.com> wrote:
>
> You can read the RFC here:
> https://wiki.php.net/rfc/static_constructor

I see that you're using zend_class_init_statics() as a hook to call
__static_construct(). This makes the initialization order
unpredictable, because static properties are initialized lazily when
the class is first used (when instantiated, when accessing constants,
etc.). Essentially, this recreates the same problem described in the
"new in initializer" RFC:

https://wiki.php.net/rfc/new_in_initializers#unsupported_positions

> New expressions continue to not be supported in (static and non-static) p=
roperty initializers and class constant initializers. The reasons for this =
are twofold:
> [snip]
> For static property initializers and class constant initializers a differ=
ent evaluation order issue arises. Currently, these initializers are evalua=
ted lazily the first time a class is used in a certain way (e.g. instantiat=
ed). Once initializers can contain potentially side-effecting expressions, =
it would be preferable to have a more well-defined evaluation order. Howeve=
r, the straightforward approach of evaluating initilizers when the class is=
 declared would break certain existing code patterns. In particular, refere=
ncing a class that is declared later in the same file would no longer work.

Lazy evaluation might be ok if order is clearly defined. Making the
order undefined makes it hard (or impossible) to understand which
symbols declared in the current file may be used from
__static_construct(). The alternative mentioned above (calling
__static_construct() at class-declaration-time) likely breaks too much
existing code (because it would also require calling static
initializers just before that, which may reference symbols declared
later on), and is further complicated by early-binding. I'm not sure
what the best approach is here.

Ilija