Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84641
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
Message-ID: <5501B77D.5010800@gmail.com>
Date: Thu, 12 Mar 2015 15:57:49 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <6D.2C.32765.10EC0055@pb1.pair.com>	<5500D967.5040800@gmail.com> <CAFMT4NqLaj6G2P9W0dhYc50yt27mmNP1vE+A=c_nYSqTotncUQ@mail.gmail.com> <13.69.64353.73451055@pb1.pair.com> <5501876C.3020107@gmail.com> <3D.85.42021.3E7A1055@pb1.pair.com>
In-Reply-To: <3D.85.42021.3E7A1055@pb1.pair.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] static constructor
From: rowan.collins@gmail.com (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.

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]