Re: static constructor

Johannes Ott wrote on 12/03/2015 17:05:

Am 12.03.2015 um 16:57 schrieb Rowan Collins:

Johannes Ott wrote on 12/03/2015 14:51:

That is nearly like initializing a class constant, but in my opinion a constant should not have a "complex" algorithm (For example conditions or read from filesystem). That should be encapsulated inside a proper method body.

I agree, but as such, I think that method should be called somewhere by the code, even if only by a DI container, not happen automagically and slurp in data from global state.

It is called somewhere in the code namely inside the static constructor :D

What I meant is that it is not executed by any piece of code the user writes, but directly by the engine based on a magic hook.

So doing a null check each time is a overhead of calculation which can be avoided with this static constructor pattern.

Presumably the engine would need to perform some implicit equivalent of "if ( ! self::$initialised )" on each call to decide if the static constructor needs to be called or not, so the overhead is not completely eliminated.

Yes you are right but I think it can be done more efficiently inside the interpreter using some struct flags then have to parse each time inside a coded part in the application.

Yes, point taken.

Incidentally, note that a recent RFC to add the ability to declare a class as static failed by 12 votes to 5 - https://wiki.php.net/rfc/abstract_final_class - and much of the discussion was around static implementations being generally inferior to instances, so I'm not alone in challenging designs that rely on them.

I will check the rfc later but "static class" sounds strange.

Basically, all your examples imply classes that consist only of static members - they're not using static helpers to create instances, they're using them *instead of* instances. This was what was mean by "static class" in that proposal. Personally, I was in favour of that, since I think such classes do exist, and a syntax for declaring them would be useful, but the most common argument against was that we should be finding ways for people to not need such classes, rather than supporting them better. This proposal sounds like it's adding facilities to classes that belong on objects, or ... somewhere else. Regards, -- Rowan Collins [IMSoP]