Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84642
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error)
Message-ID: <5501BE92.5020407@garfieldtech.com>
Date: Thu, 12 Mar 2015 11:28:02 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; 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> <5501B77D.5010800@gmail.com>
In-Reply-To: <5501B77D.5010800@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] static constructor
From: larry@garfieldtech.com (Larry Garfield)

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