Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84910
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <C9.D7.31306.C11F5055@pb1.pair.com>
To: internals@lists.php.net
Date: Sun, 15 Mar 2015 21:52:40 +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> <57.60.52108.BE854055@pb1.pair.com> <5504712D.4010103@googlemail.com> <55049B17.2060000@deroetzi.de> <550558AB.9010402@googlemail.com> <A6.E5.29489.6E165055@pb1.pair.com> <5505D3D4.2040006@gmail.com>
In-Reply-To: <5505D3D4.2040006@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 15.03.2015 um 19:47 schrieb Rowan Collins:
> On 15/03/2015 10:41, Johannes Ott wrote:
>> Okay get your point, but as already discussed several times, the rfc
>> should not be declined for the reason a ppl, who doesn't understand when
>> to use static context or when not to use at all, can do crucial things.
>> Because he although can do without the static constructor.
>>
>> For a horiffic example:
>>
>> class Example {
>>
>>       private static $handler;
>>
>>       public function open() {
>>           self::$handler = fopen('example.txt');
>>       }
>>
>>       ...
>>
>> }
>>
>> Example::open();
>>
>> Indeed I have the opinion some beginner who is doing such horiffic code
>> maybe think more about what he is doing and especially about the side
>> effects inside a so called "magic" method, then outside.
> 
> I'm not clear what's so different between this and your logger example.
> Here you have a file handle, which in PHP happens to be a special type
> rather than an object, and are storing it in a static property; closing
> the file handle has to be managed somehow, and this code is letting PHP
> do this implicitly with what amounts to a destructor on the file handle
> resource.
> 

The difference is as I told the Resource Handler is wrapped inside a
Singleton Instance with a destructor!


>> I never ever would store any kind of resources (opening any kind of
>> connections to db, file, socket etc.) directly to the static context
>> without wrapping in a instance, because those are really dynamic handles
>> which need a proper constructor and destructor for the special
>> connection.
> 
> However many intermediate instances you create, at some point the
> destructor has to run, and that will only happen once the static
> reference is unset. Luckily, the Zend Engine will go through and garbage
> collect all global and static variables at the end of a request, so you
> can cheat that way.
> 

I think that is no kind of a cheat, in my opinion this is the normal
behavior how static stored properties and instances, stored at them,
should be cleanup in every oop-language.

> Or, you can *invalidate* the objects, rather than destructing them, as
> implied by your "DBAdapter::closeAllConnections()" example - there will
> still be references to those connections live in your code if, for
> instance, you have Example::$logger, and $logger->dbConnection. You
> can't have an Example::cleanupResources() method, because it would fire
> the static constructor on pages which hadn't used the class yet,
> destroying the lazy-loading.

You always talking about the singleton-pattern, as I although told
different times now, I have no resources directly stored in static
context but in singleton instances inside.

for example the DBAdapter::closeAllConnections():

public static closeAllConnections() {
    while(count(self::$connections) > 0) {
        self::$connections[0]->close();
        unset(self::$connections[0]);
    }
}

the same for LogAdapter.

> 
> What you're really relying on is that the implicit static destructor
> provided by the engine is good enough for the kinds of resource which a
> static constructor should be dealing with. This is also true of many
> objects, which don't technically need a custom destructor to close file
> or DB handles, because Zend will reference count the resource, but more
> advanced objects can do more advanced cleanup.
> 

Yes indeed this is true, and again same sentence: resources -> inside
instances not directly inside static property.

Regards,

-- 
DerOetzi