Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84778
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <57.60.52108.BE854055@pb1.pair.com>
To: internals@lists.php.net
Date: Sat, 14 Mar 2015 16:51:03 +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> <04.FE.24603.D5CB2055@pb1.pair.com> <5503D9E8.1090008@googlemail.com>
In-Reply-To: <5503D9E8.1090008@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 14.03.2015 um 07:49 schrieb 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.
> 
> 

Yes, this could be another RFC in future but not yet.
>> 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.
> 
> 

As I already told several times, this poor code does NOT depend on a
static constructor method.

On the one hand the proposed static constructor is only a shorter
replacement of several valid user-land patterns doing the same feature
already, as you can see on the examples I or Patrick posted in this thread.

On the other hand I force the opinion, that a RFC should not be declined
for the reason someone, who is not understanding the feature and all of
if side-effects, maybe can do some crucial things with it, while it is
useful for programmers who know how to use it. Because  in my opinion,
as I already tried to figure out, you can do crucial things with every
single language feature, which is already implemented yet, if you're not
knowing how it works and use it anyway.

So we should prohibit PHP and all other languages ;) (Just fun!)

>>
>> 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.
> 
> 

A dependcy between destructors of instances, which the language have to
know by itself that sounds horrific indeed.

If one instance has destruction dependcies to other instances, you
should have used any kind of linking pattern between this instances so
the __destruct of the first instance destructed can handle the
destruction dependcies. At the moment I cannot think about any use case,
where this should be done another way. Maybe you have a concret example
for me, so I can think about this?

On destruction/unload of a class the language should be able to unset
static properties in random order for this reason, without any need of a
class destructor?!

>>
>> Regards,
> 
> Thank you!
> 

Regards,
-- 
DerOetzi