Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84762
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.82.53 as permitted sender)
Message-ID: <5503D9E8.1090008@googlemail.com>
Date: Sat, 14 Mar 2015 07:49:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: PHP Developers Mailing List <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> <5501D328.9040800@gmail.com> <98.26.24603.C9DE1055@pb1.pair.com> <5501F823.3060805@gmail.com> <B9.68.24603.1F222055@pb1.pair.com> <55028793.5040606@googlemail.com> <04.FE.24603.D5CB2055@pb1.pair.com>
In-Reply-To: <04.FE.24603.D5CB2055@pb1.pair.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] static constructor
From: cryptocompress@googlemail.com (Crypto Compress)

Am 13.03.2015 um 11:30 schrieb Johannes Ott:
> Am 13.03.2015 um 07:45 schrieb Crypto Compress:
>> Hello Johannes,
>>
>> in other mails you argue with Rowan about global state. I think it's
>> better to focus on innovation of "class context" in global scope, as
>> it's impossible to reason the disadvantages of global state away.
>> (Discussions on variable scope are painful too.)
>>
>> And two questions:
>> 1. By definition cctor is guaranteed to be executed only once. Right?
> Yes as the __static should be as well. See discussion with Rowan and
> Patrick for details.
>
> As I already told, I still have to clearify howto react if an exception
> occurs inside the static class constructor. I prefer at the moment the
> variant that a second try will raise a fatal error. But I will think
> about this before I'll prepare the RFC.
>
>> 2. In your examples you employ some external resources in cctor (e.g.
>> logger, db, ini-files). Do you intend to propose a cdtor to release this
>> resources?
> For my understanding the lifecycle of a class is from the loading of the
> class definition to the end of the application or until some explicit
> class unload (don't know whether php has such feature).

PHP has no explicit class domain unload feature and you do not plan to 
implement this. Okay.


> If loading a
> instance to a static member you must be aware that this instance will
> live till the end of lifetime of the class (that is the basic of
> static). But at the end I hope PHP is unsetting all static members as
> well, which should trigger the destructor of this instance as well.
>
> If PHP is not reacting like this (but I'm sure it is because without all
> suggested singletons here would be a huge memory and connection leak as
> well), I know what my second rfc would be :D
>
> Second point if you open a resource to read some data inside a method
> and do not assure that it is closed again either explicit inside the
> method or on a global pattern (for example my DBAdapter I use to read,
> holds a single connection to database which is closed at the very end of
> run), this would be poor code inside the static constructor as well as
> it would be inside every other method.

This "poor code inside the static constructor" seems to be a crucial 
point of your RFC.


>
> So I do not see the need of a explicit class deconstructor, because the
> language should already react correctly on this issues as I can see so far

The language cannot know the order of dependencies and how to destruct them.


>
> Regards,

Thank you!