Hi Erick On Wed, Jun 19, 2024 at 2:34 PM Erick de Azevedo Lima <ericklima.c...@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) > property initializers and class constant initializers. The reasons for this > are twofold: > [snip] > 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. 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
