Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123688
Message-ID: <CA61EBA8-FF26-4209-A3D4-075958F046A5@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_AE5FE2D3-94A4-41B7-A415-C1DD3C807C0E"
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] [RFC] Static Constructor
Date: Wed, 19 Jun 2024 17:55:18 -0400
In-Reply-To: <CAPyj-LC6k+w9CnTjLn_4js8tTTPd1wY2Pu6F54NMQbc2RcRxhA@mail.gmail.com>
Cc: php internals <internals@lists.php.net>
To: Ilija Tovilo <tovilo.ilija@gmail.com>
References: <CAGS0MVC9q+byG_Gogt+kb84TSVKG-FV+5xM=vMTZWQ+nyi4g_g@mail.gmail.com>
 <CAPyj-LC6k+w9CnTjLn_4js8tTTPd1wY2Pu6F54NMQbc2RcRxhA@mail.gmail.com>
From: mike@newclarity.net (Mike Schinkel)


--Apple-Mail=_AE5FE2D3-94A4-41B7-A415-C1DD3C807C0E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Jun 19, 2024, at 2:36 PM, Ilija Tovilo <tovilo.ilija@gmail.com> =
wrote:
> On Wed, Jun 19, 2024 at 2:34=E2=80=AFPM 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.
>=20
> 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>=20=

--Apple-Mail=_AE5FE2D3-94A4-41B7-A415-C1DD3C807C0E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
Jun 19, 2024, at 2:36 PM, Ilija Tovilo &lt;<a =
href=3D"mailto:tovilo.ilija@gmail.com" =
class=3D"">tovilo.ilija@gmail.com</a>&gt; wrote:</div><div class=3D""><div=
 class=3D"">On Wed, Jun 19, 2024 at 2:34=E2=80=AFPM Erick de Azevedo =
Lima<br class=3D"">&lt;<a href=3D"mailto:ericklima.comp@gmail.com" =
class=3D"">ericklima.comp@gmail.com</a>&gt; wrote:<br =
class=3D""><blockquote type=3D"cite" class=3D"">New expressions continue =
to not be supported in (static and non-static) property initializers and =
class constant initializers. The reasons for this are twofold:<br =
class=3D"">[snip]<br class=3D"">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.<br class=3D""></blockquote><br class=3D"">Lazy evaluation =
might be ok if order is clearly defined. =
</div></div></blockquote><div><br class=3D""></div><div>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.</div><div><br class=3D""></div><div>Here [2] is a =
discussion on StackOverflow of "hooks" that should be eagerly =
loaded.</div><div><br class=3D""></div><div>Thus I think it important =
that if&nbsp;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.:</div><div><br class=3D""></div><div>class Foo {</div><div>&nbsp; =
&nbsp;&nbsp;private&nbsp;static =
lazy&nbsp;function&nbsp;__staticConstruct():void {<div class=3D"">&nbsp; =
&nbsp; &nbsp; &nbsp; // Do initialization stuff here<br class=3D"">&nbsp; =
&nbsp;&nbsp;}</div></div><div>}</div><div><br class=3D""></div><div><br =
class=3D""></div><div>-Mike</div><div>[1]&nbsp;<a =
href=3D"https://externals.io/message/123675#123684" =
class=3D"">https://externals.io/message/123675#123684</a></div><div>[2]&nb=
sp;<a href=3D"https://stackoverflow.com/a/2400206/102699" =
class=3D"">https://stackoverflow.com/a/2400206/102699</a>&nbsp;</div></div=
></body></html>=

--Apple-Mail=_AE5FE2D3-94A4-41B7-A415-C1DD3C807C0E--