Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123692
Precedence: bulk
MIME-Version: 1.0
References: <CAGS0MVC9q+byG_Gogt+kb84TSVKG-FV+5xM=vMTZWQ+nyi4g_g@mail.gmail.com>
 <CAPyj-LC6k+w9CnTjLn_4js8tTTPd1wY2Pu6F54NMQbc2RcRxhA@mail.gmail.com> <CA61EBA8-FF26-4209-A3D4-075958F046A5@newclarity.net>
In-Reply-To: <CA61EBA8-FF26-4209-A3D4-075958F046A5@newclarity.net>
Date: Thu, 20 Jun 2024 10:57:09 +0200
Message-ID: <CANS-=pfiLvBNqWBVYkg3mF0ho_rbO7_z97CygqAwih9OL3w6EQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Static Constructor
To: Mike Schinkel <mike@newclarity.net>
Cc: Ilija Tovilo <tovilo.ilija@gmail.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a09556061b4e81df"
From: kjarli@gmail.com (Lynn)

--000000000000a09556061b4e81df
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 19, 2024 at 11:57=E2=80=AFPM Mike Schinkel <mike@newclarity.net=
> wrote:

> 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 th=
is
> are twofold:
> [snip]
> For static property initializers and class constant initializers a
> different evaluation order issue arises. Currently, these initializers ar=
e
> 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 evaluatio=
n
> order. However, the straightforward approach of evaluating initilizers wh=
en
> 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 previou=
s
> 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
> [2] https://stackoverflow.com/a/2400206/102699
>

Seeing an extra keyword made me think of:
```php
class Foo
{
    public constructor __construct() {}
    public destructor __destruct() {}
    public static constructor __construct() {}
    public static destructor __destruct() {} // probably doesn't make sense
right now
}
```
This syntax would allow named constructors in the future, or even omitting
the default name.
```php
class Foo
{
    public constructor() {}
    public destructor() {}

    public constructor create(int $id)
    {
        $this->id =3D $id; // no need to call the default __construct, nor
needs to return
    }
}
```
Not sure if this is even a desired path to take, just wanted to throw the
idea out there.

--000000000000a09556061b4e81df
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jun 19, 2024 at 11:57=E2=80=
=AFPM Mike Schinkel &lt;<a href=3D"mailto:mike@newclarity.net">mike@newclar=
ity.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div style=3D"overflow-wrap: break-word;"><div><blockquote type=3D"c=
ite"><div>On Jun 19, 2024, at 2:36 PM, Ilija Tovilo &lt;<a href=3D"mailto:t=
ovilo.ilija@gmail.com" target=3D"_blank">tovilo.ilija@gmail.com</a>&gt; wro=
te:</div><div><div>On Wed, Jun 19, 2024 at 2:34=E2=80=AFPM Erick de Azevedo=
 Lima<br>&lt;<a href=3D"mailto:ericklima.comp@gmail.com" target=3D"_blank">=
ericklima.comp@gmail.com</a>&gt; wrote:<br><blockquote type=3D"cite">New ex=
pressions continue to not be supported in (static and non-static) property =
initializers and class constant initializers. The reasons for this are twof=
old:<br>[snip]<br>For static property initializers and class constant initi=
alizers a different evaluation order issue arises. Currently, these initial=
izers are evaluated lazily the first time a class is used in a certain way =
(e.g. instantiated). Once initializers can contain potentially side-effecti=
ng expressions, it would be preferable to have a more well-defined evaluati=
on order. However, the straightforward approach of evaluating initilizers w=
hen the class is declared would break certain existing code patterns. In pa=
rticular, referencing a class that is declared later in the same file would=
 no longer work.<br></blockquote><br>Lazy evaluation might be ok if order i=
s clearly defined. </div></div></blockquote><div><br></div><div>Consider th=
at some uses for a static function need to always occur no matter whether o=
r not any other method of the class is called. My previous email [1] covere=
d several.</div><div><br></div><div>Here [2] is a discussion on StackOverfl=
ow of &quot;hooks&quot; that should be eagerly loaded.</div><div><br></div>=
<div>Thus I think it important that if=C2=A0lazy evaluation is used for sta=
tic initializers then it should be an option, and ideally one that is opt-i=
n vs. opt-out, e.g.:</div><div><br></div><div>class Foo {</div><div>=C2=A0 =
=C2=A0=C2=A0private=C2=A0static lazy=C2=A0function=C2=A0__staticConstruct()=
:void {<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // Do initialization stuff here<br>=
=C2=A0 =C2=A0=C2=A0}</div></div><div>}</div><div><br></div><div><br></div><=
div>-Mike</div><div>[1]=C2=A0<a href=3D"https://externals.io/message/123675=
#123684" target=3D"_blank">https://externals.io/message/123675#123684</a></=
div><div>[2]=C2=A0<a href=3D"https://stackoverflow.com/a/2400206/102699" ta=
rget=3D"_blank">https://stackoverflow.com/a/2400206/102699</a>=C2=A0</div><=
/div></div></blockquote><div><br></div><div>Seeing an extra keyword made me=
 think of:</div><div>```php</div><div>class Foo</div><div>{</div><div>=C2=
=A0 =C2=A0 public constructor __construct() {}</div><div>=C2=A0 =C2=A0 publ=
ic destructor __destruct() {}</div><div>=C2=A0 =C2=A0 public static constru=
ctor __construct() {}</div><div>=C2=A0 =C2=A0 public static destructor __de=
struct() {} // probably doesn&#39;t make sense right now</div><div>}</div><=
div>```=C2=A0</div><div>This syntax would allow named constructors in the f=
uture, or even omitting the default name.<br>```php<br><div>class Foo</div>=
<div>{</div><div>=C2=A0 =C2=A0 public constructor() {}</div><div>=C2=A0 =C2=
=A0 public destructor() {}</div><div><br></div><div>=C2=A0 =C2=A0 public co=
nstructor create(int $id)</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 $this-&gt;id =3D $id; // no need to call the default __const=
ruct, nor needs to return</div><div>=C2=A0 =C2=A0 }</div><div>}</div>```</d=
iv><div>Not sure if this is even a desired path to take, just wanted to thr=
ow the idea out there.</div><div><br></div></div></div>

--000000000000a09556061b4e81df--