Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84943
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.173 as permitted sender)
Message-ID: <550604E1.9040506@gmail.com>
Date: Sun, 15 Mar 2015 22:17:05 +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> <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> <C9.D7.31306.C11F5055@pb1.pair.com>
In-Reply-To: <C9.D7.31306.C11F5055@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)

On 15/03/2015 20:52, Johannes Ott wrote:
> 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!

Whether the instance is a singleton, or has a non-default destructor, 
makes no difference - the cleanup happens during PHP's shutdown 
procedure. As it happens, resources have the equivalent of destructors 
internally, so even the object instance vs resource doesn't actually 
matter here.


>> 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.

This doesn't destroy those objects - PHP is a purely garbage collected 
language (in the sense of no manually managed memory / resources), so 
you can't destroy an object something still points to. If you gave out a 
reference to a DB connection and stored it in a static variable 
somewhere, that reference still ponts to the object, and you will have 
to detect that it is a closed connection and handle it appropriately.

This isn't to do with public constructors vs singletons, or even objects 
vs resources, it's about the handle being shared amongst multiple users, 
no one of which can unilaterally "unshare" it.

My point about lazy-loading is that if you have a class like this...

class LazyThing {
private static $foo;
private function __static() { self::$foo = 
Something::GetSomeKindOfWrappedResource(); }
public function cleanup() { self::$foo->destroy(); }
}

...and then don't need it on a particular page, when you call 
LazyThing::cleanup(), it will actually trigger the static constructor, 
potentially triggering a whole chain of resources to be opened just in 
order to close them again. If that's the case, then you might as well 
have a matching pair of Foo::initialise() and Foo::cleanup() calls which 
are both called explicitly.

So explicit cleanup routines can't usefully be used in the same class as 
implicit initialisation, which kind of makes sense, but rules them out 
as an alternative to static destructors.

Regards,

-- 
Rowan Collins
[IMSoP]