Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84674
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <04.FE.24603.D5CB2055@pb1.pair.com>
To: internals@lists.php.net
Date: Fri, 13 Mar 2015 11:30:49 +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> <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>
In-Reply-To: <55028793.5040606@googlemail.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 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). 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.

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

Regards,
-- 
DerOetzi