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::__construct
Before accessing C1::$v1 variable
calling C1::__staticConstruct
C2::USING_SYMBOL_DECLARED_LATER
2024-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