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