Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84645
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <85.D1.24603.247C1055@pb1.pair.com>
To: internals@lists.php.net
Date: Thu, 12 Mar 2015 18:05:01 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
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
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] static constructor
From: mail@deroetzi.de (Johannes Ott)

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

> 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.
> 

Okay that is a point each developer should be aware and decide by his self.

>> 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.

> 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.

> Regards,


Regards,
-- 
DerOetzi