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.
Consider your "prepare some SQL queries" example - it has a dependency on a database connection, so that now has to be global state; if that in turn is lazily initialised, it needs to get the connection string from yet more global state, and so on. By using the class constructor, you are forced to hard-code those dependencies - there's no parameters to pass them in, and you can't pre-initialise them from outside the class, because nothing on the class can run before the class constructor.
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.
I agree the real creation(/parsing) of the class should have no side-effects. But the static constructor is not executed at the creation-time of the class but directly before first access on the class. That are two totally different moments in the lifecycle of the class and does not block the possibility to first read all classes without any side-effects.
OK, I misunderstood this part. So this is like the private constructor of a Singleton, a lazy initialisation the first time you use it. (Sorry to bang on about Singletons; they're what I know, so I'm trying to understand the similarities and differences.)
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.
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
