> On Sep 11, 2021, at 7:35 PM, Marco Pivetta <ocram...@gmail.com> wrote: > > On Sun, 12 Sep 2021, 01:28 David Rodrigues, <david.pro...@gmail.com> wrote: > >> Hello! >> >> I would like to suggest a feature I saw being implemented in the V8 9.4 >> engine called "*class static initialization block*". >> >> https://v8.dev/blog/v8-release-94 >> >> In short, it is a method that is executed once when a class is imported and >> loaded, allowing for some more advanced initialization process to be done. >> >> class Test { >> static readonly Carbon $now; >> >> static () { >> self::$now = now(); >> } >> } >> >> Currently I can only do this in a very hacky way, usually by creating a >> public static method and calling it after class initialization. >> >> class Test { >> static Carbon $now; >> >> public static function init(): void { >> self::$now = now(); >> } >> } >> >> Test::init(); >> >> I think the way the V8 does is much more interesting. >> >> Another alternative would be to create a magic method like __initialize(). >> > > This already works without any magic.
Not true. Here are three (3) things you cannot currently do with your proposed solution and without said magic: 1.) Use static analysis to recognize a class has an initialization functionality and thus provide lint-specific to best practices for static initialization. 2.) Make the initialization function private. 3.) Override and/or change order of initialization of parent in child class. I do not know of use-cases of #3, but #1 and #2 use-case should be obvious. > ``` > MyClass::horribleInitializationPractices(); > ``` You named that in a rather condescending and passive-aggressive way. Is that really helpful for respectful dialog? > That's really all there is to it. > > What you define as hacky is really normal/boring, and does not need special > constructs. > > Also, it's generally not a good idea to sprinkle static mutable > runtime-bound all over the place: it should be an exception, not a rule. Valid use-cases I have come across: 1. Hooking actions and filters in plugins for frameworks and CMS that use hooks as an extension mechanism. 2. Initializing what would ideally be constants but because of PHP's constraints regarding constant initializes cannot be constants. > On Sep 12, 2021, at 6:42 AM, Rowan Tommins <rowan.coll...@gmail.com> wrote: > > On 12 September 2021 00:28:02 BST, David Rodrigues <david.pro...@gmail.com> > wrote: >> Hello! >> >> I would like to suggest a feature I saw being implemented in the V8 9.4 >> engine called "*class static initialization block*". > > > Hi David, > > There was a similar proposal for PHP a few years ago: > https://wiki.php.net/rfc/static_class_constructor > > Although it didn't go to a vote, the proposal was dropped for lack of > support. There's some discussion summarised in that RFC, and you can probably > find the rest by searching for its title on https://externals.io > > Regards, > > -- > Rowan Tommins Here is the external thread: https://externals.io/message/84602 Rowan, you were definitely the most vocal one to argue against it with the most messages on that thread. But all the arguments against appeared to bog down into discrediting Johannes Ott's desired use-case for static class constructors and did not really look for other reason why they would be useful. As I mentioned above, hooking actions and filters in plugins for frameworks and CMS is where it would be useful, especially since these generally need to be hooked upon initial load of the plugin. Also, initializing variables to act as constants because PHP does not support complex initializations on constants is another use-case. One of your arguments against was the timing of the initialization because evidently Johannes Ott wanted them to be lazily evaluated. Given the use-case I just stated I think they should always be loaded immediately whenever the file is loaded. That makes that argument about debugging cause-and-effect becomes a moot point. And lazy evaluation should be considered as a separate feature. I blogged about that a while back but never brought to the list: https://mikeschinkel.org/2021/lets-add-lazy-evaluation-to-php/ The other main argument you had against was Singletons. But that was a moot point because one of the reasons to use static initialization *is* to instantiate a Singleton. Java has static initialization blocks[1], C# has static constructors[2] so the idea they would be useful for PHP is not a stretch, -Mike [1] https://www.geeksforgeeks.org/g-fact-79/ [2] https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/static-constructors -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
