Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84648
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.175 as permitted sender)
Message-ID: <5501D328.9040800@gmail.com>
Date: Thu, 12 Mar 2015 17:55:52 +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> <5501B77D.5010800@gmail.com> <85.D1.24603.247C1055@pb1.pair.com>
In-Reply-To: <85.D1.24603.247C1055@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 17:05:
> 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

What I meant is that it is not executed by any piece of code the user 
writes, but directly by the engine based on a magic hook.


>>> 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.

Yes, point taken.


>> 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.

Basically, all your examples imply classes that consist only of static 
members - they're not using static helpers to create instances, they're 
using them *instead of* instances. This was what was mean by "static 
class" in that proposal. Personally, I was in favour of that, since I 
think such classes do exist, and a syntax for declaring them would be 
useful, but the most common argument against was that we should be 
finding ways for people to not need such classes, rather than supporting 
them better. This proposal sounds like it's adding facilities to classes 
that belong on objects, or ... somewhere else.

Regards,
-- 
Rowan Collins
[IMSoP]