Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123695
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:01:06 -0300
Message-ID: <CAGS0MVBxPMsLpnjk7+i7a5iftyRSVQHZFDqTSnmKXmgh9TLdFg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Static Constructor
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009d80e5061b51eabc"
From: ericklima.comp@gmail.com (Erick de Azevedo Lima)

--0000000000009d80e5061b51eabc
Content-Type: text/plain; charset="UTF-8"

Hi all.

Answering to Larry:
> More complex initialization of things like lookup tables or "dynamic
constants" (like if you wanted to record "now" to use for later
comparisons).
Those are my use cases, to be honest.

> For that reason, therefore, I don't like the current approach, especially
for this line: "Programmers have the option to call the __staticConstruct
method to reset static properties values if desired."
I just laughed at myself when I read this. As I said, my main inspiration
was the C# implementation and there, the static constructor can only be
called by the engine.
And that was my intention, but then I remembered that the "__construct"
method can be called on an already constructed object and I implemented it
this way.
If it's a consensus to remove it, I'll gladly do it. :-)

> Your examples would be clearer if you leveraged the ??= operator, which
would reduce your initializeMinDate() methods to a single line.
Yes, it's true. As a former teaching assistant, I tend to give examples
that might be longer than necessary, with the intention of being as clear
as possible.
In this case, it was to emphasize the fact that we must implement a logic
to check (the "if" at the beginning of the method) if the property was
already initialized.

> What I object to is holding up Java as being "stricter about OO
principles."  OO principles are not a uniform, monolithic thing.
> In fact, the person who invented the term Object-Oriented has said before
that C++ and Java are *not* what he had in mind.
> "Class based programming" is not what OOP was intended to be.
To be honest, when I wrote this part, I was indeed thinking about "class
based" programming.
And Java is stricter than PHP and C++ in this sense: It does not have loose
functions, everything must be inside a class.
And even though "Class based programming" is not what OOP was intended to
be, it's what's mostly found out there: OOP = Class based programming
But my main point here is to show that this feature is often provided
because it's proven to be useful for programmers of multiple programming
languages.

Answering to Mike:

> I noticed you did not include an example for Go so I wrote one up for you
in a Go playground. Hopefully you can include Go's approach in your RFC?
No, I'm not familiar enough with Go to provide examples, so I did not
consider it. As you provided the example, I'll gladly include it. Thank you!

> To elaborate more about "best practices" where I see static initializers
being especially valuable it when you want to initialize *immutable* data,
> and especially when that data is in complex form such as an object vs.
just a simple value.
Yes, I think that's "the" use case.

Tim:

> I would suggest `__constructStatic()`. This matches the existing naming
> pattern of `__callStatic()` being the companion to `__call()`.
Noted. I'm not really attached to any name and your point makes a lot of
sense.

Ilija:

> I see that you're using zend_class_init_statics() as a hook to call
__static_construct().
Yes, I thought that lazy initialization would cover most of the use-cases
for initializing static variables, so that seemed the best place to do it.

> This makes the initialization order
> unpredictable, because static properties are initialized lazily when
> the class is first used (when instantiated, when accessing constants,
etc.).
From my tests, the static variables initialization is even lazier: The
"zend_class_init_statics" is only called when you try to access a static
variable.
See this example:

class C1
{
    private static \DateTimeInterface $v1;

    public function __construct()
    {
        echo __METHOD__ . PHP_EOL;
    }

    private static function __staticConstruct()
    {
        self::$v1 = new \DateTimeImmutable('2024-06-19 00:00:00');
        echo 'calling ' . __METHOD__ . PHP_EOL;
        echo C2::USING_SYMBOL_DECLARED_LATER . PHP_EOL;
    }

    public static function getV1()
    {
        echo 'Before accessing C1::$v1 variable' . PHP_EOL;

        return self::$v1;
    }
}

class C2
{
    public const USING_SYMBOL_DECLARED_LATER =
'C2::USING_SYMBOL_DECLARED_LATER';
}

$obj1 = new C1(); //should not trigger zend_class_init_statics()

echo C1::getV1()->format('Y-m-d') . PHP_EOL; //

This example prints:





*C1::__constructBefore accessing C1::$v1 variablecalling
C1::__staticConstructC2::USING_SYMBOL_DECLARED_LATER2024-06-19*

> 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()
Can you provide an example for that? I'm not sure if I understood
everything correctly.

> ... is further complicated by early-binding. I'm not sure what the best
approach is here.
One of my first thoughts was to perform this at the end of class linking
(on function *zend_do_link_class*()),
but then I came to a conclusion that performing it during the already
existing lazy init would cover most use cases.

Mike again:

> 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.
Yes, I considered this approach before. But then I realized that for
covering the properties initialization,
this already existing lazy loading mechanism would suffice. At the end of
the RFC,
I consider future scope to create an early-init. In my opinion, as it
covers a more general use for this init,
it should be implemented maybe using another magic method, like "__load" or
"__link",
which would be hooks on class loading process and not specific to static
variables initialization

Lynn:

> Not sure if this is even a desired path to take, just wanted to throw the
idea out there.
Looking at the idea, I like the new "method modifiers". But it would be a
much bigger scope to tackle right now.

Best regards,
Erick

--0000000000009d80e5061b51eabc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi all.</div><div><br></div><div>Answering to Larry:<=
br></div><div>&gt; More complex initialization of things like lookup tables=
 or &quot;dynamic=20
constants&quot; (like if you wanted to record &quot;now&quot; to use for la=
ter=20
comparisons).</div><div>Those are my use cases, to be honest.</div><div><br=
>&gt; For that reason, therefore, I don&#39;t like the current approach,=20
especially for this line: &quot;Programmers have the option to call the=20
__staticConstruct method to reset static properties values if desired.&quot=
;<br></div><div>I just laughed at myself when I read this. As I said, my ma=
in inspiration was the C# implementation and there, the static constructor =
can only be called by the engine.</div><div>And that was my intention, but =
then I remembered that the &quot;__construct&quot; method can be called on =
an already constructed object and I implemented it this way.</div><div>If i=
t&#39;s a consensus to remove it, I&#39;ll gladly do it. :-)<br><br>&gt; Yo=
ur examples would be clearer if you leveraged the ??=3D operator, which=20
would reduce your initializeMinDate() methods to a single line.</div><div>Y=
es, it&#39;s true. As a former teaching assistant, I tend to give examples =
that might be longer than necessary, with the intention of being as clear a=
s possible.</div><div>In this case, it was to emphasize the fact that we mu=
st implement a logic to check (the &quot;if&quot; at the beginning of the m=
ethod) if the property was already initialized.</div><div><br></div><div>&g=
t; What I object to is holding up Java as being &quot;stricter about OO=20
principles.&quot;=C2=A0 OO principles are not a uniform, monolithic thing.<=
/div><div>&gt; In=20
fact, the person who invented the term Object-Oriented has said before=20
that C++ and Java are *not* what he had in mind.</div><div>&gt; &quot;Class=
 based=20
programming&quot; is not what OOP was intended to be. <br></div><div>To be =
honest, when I wrote this part, I was indeed thinking about &quot;class bas=
ed&quot; programming.</div><div>And Java is stricter than PHP and C++ in th=
is sense: It does not have loose functions, everything must be inside a cla=
ss.</div><div>And even though &quot;Class based=20
programming&quot; is not what OOP was intended to be, it&#39;s what&#39;s m=
ostly found out there: OOP =3D Class based programming</div><div>But my mai=
n point here is to show that this feature is often provided because it&#39;=
s proven to be useful for programmers of multiple programming languages.</d=
iv><div><br></div><div>Answering to Mike:</div><div><br></div><div><div>&gt=
; I noticed you did not include an example for Go so I wrote one up=20
for you in a Go playground. Hopefully you can include Go&#39;s approach in=
=20
your RFC?</div><div>No, I&#39;m not familiar enough with Go to provide exam=
ples, so I did not consider it. As you provided the example, I&#39;ll gladl=
y include it. Thank you!<br></div><div><br>&gt; To elaborate more about &qu=
ot;best practices&quot; where I see static initializers
 being especially valuable it when you want to initialize <b>immutable</b> =
data,</div><div>&gt; and especially when that data is in complex form such =
as an object vs. just a simple value.<br></div><div>Yes, I think that&#39;s=
 &quot;the&quot; use case.<br><br></div><div>Tim:<br><br>&gt; I would sugge=
st `__constructStatic()`. This matches the existing naming <br>&gt; pattern=
 of `__callStatic()` being the companion to `__call()`.</div><div>Noted. I&=
#39;m not really attached to any name and your point makes a lot of sense.<=
br></div></div><div><br></div><div>Ilija:</div><div><br>&gt; I see that you=
&#39;re using zend_class_init_statics() as a hook to call __static_construc=
t().</div><div>Yes, I thought that lazy initialization would cover most of =
the=20
use-cases for initializing static variables, so that seemed the best=20
place to do it.</div><div><br></div><div>&gt; This makes the initialization=
 order<br>
&gt; unpredictable, because static properties are initialized lazily when<b=
r>&gt;=20
the class is first used (when instantiated, when accessing constants, etc.)=
.<br>From my tests, the static variables initialization is even lazier: The=
 &quot;zend_class_init_statics&quot; is only called when you try to access =
a static variable.</div><div>See this example:<br><br><span style=3D"font-f=
amily:monospace">class C1<br>{<br>=C2=A0 =C2=A0 private static \DateTimeInt=
erface $v1;<br><br>=C2=A0 =C2=A0 public function __construct()<br>=C2=A0 =
=C2=A0 {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 echo __METHOD__ . PHP_EOL;<br>=C2=
=A0 =C2=A0 }<br><br>=C2=A0 =C2=A0 private static function __staticConstruct=
()<br>=C2=A0 =C2=A0 {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 self::$v1 =3D new \Dat=
eTimeImmutable(&#39;2024-06-19 00:00:00&#39;);<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 echo &#39;calling &#39; . __METHOD__ . PHP_EOL;<br>=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 echo C2::USING_SYMBOL_DECLARED_LATER . PHP_EOL;<br>=C2=A0 =C2=A0 }<=
br><br>=C2=A0 =C2=A0 public static function getV1()<br>=C2=A0 =C2=A0 {<br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 echo &#39;Before accessing C1::$v1 variable&#39=
; . PHP_EOL;<br><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return self::$v1;<br>=C2=A0=
 =C2=A0 }<br>}<br><br>class C2<br>{<br>=C2=A0 =C2=A0 public const USING_SYM=
BOL_DECLARED_LATER =3D &#39;C2::USING_SYMBOL_DECLARED_LATER&#39;;<br>}<br><=
br>$obj1 =3D new C1(); //should not trigger zend_class_init_statics()<br><b=
r>echo C1::getV1()-&gt;format(&#39;Y-m-d&#39;) . PHP_EOL; //<br><br>This ex=
ample prints:</span></div><div><span style=3D"font-family:monospace"><br></=
span></div><div><b><span style=3D"font-family:monospace">C1::__construct<br=
>Before accessing C1::$v1 variable<br>calling C1::__staticConstruct<br>C2::=
USING_SYMBOL_DECLARED_LATER<br>2024-06-19</span></b></div><div><br></div><d=
iv>&gt; Lazy evaluation might be ok if order is clearly defined. Making the=
<br>&gt; order undefined makes it hard (or impossible) to understand which<=
br>&gt; symbols declared in the current file may be used from __static_cons=
truct()<br></div><div>Can you provide an example for that? I&#39;m not sure=
 if I understood everything correctly.<br></div><div><br></div><div>&gt; ..=
. is further complicated by early-binding. I&#39;m not sure what the best a=
pproach is here.<font color=3D"#888888"><br></font></div><div>One of my fir=
st thoughts was to perform this at the end of class linking (on function <b=
>zend_do_link_class</b>()),</div><div>but then I came to a conclusion that =
performing it during the already existing lazy init would cover most use ca=
ses.<br></div><div></div><div><br></div><div>Mike again:<br><br>&gt; Consid=
er that some uses for a static function need to always occur=20
no matter</div><div>&gt; whether or not any other method of the class is ca=
lled. My=20
previous email [1] covered several.</div><div><div>&gt; Here [2] is a discu=
ssion on StackOverflow of &quot;hooks&quot; that should be eagerly loaded.<=
/div></div><div>Yes, I considered this approach before. But then I realized=
 that for covering the properties initialization, <br></div><div>this alrea=
dy existing lazy loading mechanism would suffice. At the end of the RFC,</d=
iv><div>I consider future scope to create an early-init. In my opinion, as =
it covers a more general use for this init,</div><div>it should be implemen=
ted maybe using another magic method, like &quot;__load&quot; or &quot;__li=
nk&quot;,</div><div>which would be hooks on class loading process and not s=
pecific to static variables initialization</div><div><br></div><div>Lynn:</=
div><div><br></div><div>&gt; Not sure if this is even a desired path to tak=
e, just wanted to throw the idea out there.</div><div>Looking at the idea, =
I like the new &quot;method modifiers&quot;. But it would be a much bigger =
scope to tackle right now.</div><div></div><div><br></div><div><div>Best re=
gards,</div><div>Erick<br></div></div></div>

--0000000000009d80e5061b51eabc--