Re: [RFC] Static Constructor

From: Date: Wed, 19 Jun 2024 21:55:18 +0000
Subject: Re: [RFC] Static Constructor
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-123688@lists.php.net to get a copy of this message
> On Jun 19, 2024, at 2:36 PM, Ilija Tovilo <tovilo.ilija@gmail.com> wrote: > On Wed, Jun 19, 2024 at 2:34 PM Erick de Azevedo Lima > <ericklima.comp@gmail.com> wrote: >> 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. Consider that some uses for a static function need to always occur no matter whether or not any other method of the class is called. My previous email [1] covered several. Here [2] is a discussion on StackOverflow of "hooks" that should be eagerly loaded. Thus I think it important that if lazy evaluation is used for static initializers then it should be an option, and ideally one that is opt-in vs. opt-out, e.g.: class Foo { private static lazy function __staticConstruct():void { // Do initialization stuff here } } -Mike [1] https://externals.io/message/123675#123684 <https://externals.io/message/123675#123684> [2] https://stackoverflow.com/a/2400206/102699 <https://stackoverflow.com/a/2400206/102699>

« previous php.internals (#123688) next »