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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
