Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84784 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 75475 invoked from network); 14 Mar 2015 20:33:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Mar 2015 20:33:31 -0000 X-Host-Fingerprint: 87.163.225.237 p57A3E1ED.dip0.t-ipconnect.de Received: from [87.163.225.237] ([87.163.225.237:7362] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 87/C0-03391-B1B94055 for ; Sat, 14 Mar 2015 15:33:31 -0500 To: internals@lists.php.net,Crypto Compress Message-ID: <55049B17.2060000@deroetzi.de> Date: Sat, 14 Mar 2015 21:33:27 +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> <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> <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> In-Reply-To: <5504712D.4010103@googlemail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Posted-By: 87.163.225.237 Subject: Re: [PHP-DEV] static constructor From: mail@deroetzi.de (Johannes Ott) Am 14.03.2015 um 18:34 schrieb Crypto Compress: > >>>> 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? > > a) Implicit order of dependencies: > Logger should be the last destructed > DatabaseLogger before FileLogger before error_log-Logger... > > b) How to destruct: > Write "Bye!" before closing socket. > > >> 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?! > > Reverse creation order. Sorry for replying to myself, but I'm just preparing the RFC and while reading the complete thread again. I think I now get the misunderstanding I had on your destructor question and want to clear that: > 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? 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. If I use inside the static constructor only for reading purpose and have to ensure that they are closed again. This can be done directly inside the static constructor or in case of my DBAdapter holding the DBConnection instance at the very end of my application. For example class Example { private static $dataFromFile; private static $dataFromDB; private static $localReferenceToLogger; private static function __static() { //Read from file $fHandle = fopen('example.ini', 'r'); self::$dataFromFile = fread($fHandle, 1024); fclose($fHandle); //Shorted DB Example self::$dataFromDB = DBAdapter::readFromDB(); //Get local Reference to logger instance; self::$localReferenceToLogger = LogAdapter::getLoggerInstance(self::class); } } //Somewhere at the end of my application DBAdapter::closeAllConnections(); Hope I could get some light to the problem you meant? Regards, -- DerOetzi