On 3/12/15 10:57 AM, Rowan Collins wrote:
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,
I thought it sounded familiar. Also check the list archive for "A
modest proposal: __constructStatic" from a month ago. It was rejected
then, too.
Really, I cannot think of any cases where I want to have a static class
self-initialize with global data (because all statics are just globals
with a fancy dress) where I wouldn't slap myself for being stupid and
not just making a proper object, factory, DI, or any number of other
options are are 10x more testable and reusable and verifiable. Sure
there's places you could use it; there's just much better options
already available in the language and have been for a decade.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
