Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84781 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64295 invoked from network); 14 Mar 2015 17:34:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Mar 2015 17:34:44 -0000 Authentication-Results: pb1.pair.com header.from=cryptocompress@googlemail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=cryptocompress@googlemail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.82.171 as permitted sender) X-PHP-List-Original-Sender: cryptocompress@googlemail.com X-Host-Fingerprint: 74.125.82.171 mail-we0-f171.google.com Received: from [74.125.82.171] ([74.125.82.171:34581] helo=mail-we0-f171.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F3/10-62718-23174055 for ; Sat, 14 Mar 2015 12:34:43 -0500 Received: by wegp1 with SMTP id p1so11679666weg.1 for ; Sat, 14 Mar 2015 10:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/zo2lAz70Btg7h3CvBrjYY3gnIYaG80+p00H/AKSAck=; b=Ql95YuKTm+f/EFkOPNSGx0PFkETmOKl5PFx/2CAJkAJI+FUPiB13xk/EhzVNH9HZuF w1fRyaBNTx554Rscya3j7ASMbGB+/HcGknrU55k39LfdIT6xH2Pz8ut3pIjNBQ4c6+YQ deVPxZT7uRjc7QkHRxDZypDDvMLOiPfJetZB5Gt/otSNqqVYuM2wzslU1XvWdOQKMCwo 4So8BvDI2AwyN40APilg0bNN77hqCBANiAYHm03EO1OB7m+dKfTIcB5OoSCig6XH6s44 wxkc31BqbaehOCfmR7K1A//OgbCQk66pxY1wV2upHwj/2dk8WYLAMSbavrf82RRCW18y BjpQ== X-Received: by 10.194.62.198 with SMTP id a6mr108999516wjs.90.1426354479998; Sat, 14 Mar 2015 10:34:39 -0700 (PDT) Received: from [192.168.1.115] (mnch-5d858cf9.pool.mediaWays.net. [93.133.140.249]) by mx.google.com with ESMTPSA id hl15sm7818340wib.3.2015.03.14.10.34.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Mar 2015 10:34:39 -0700 (PDT) Message-ID: <5504712D.4010103@googlemail.com> Date: Sat, 14 Mar 2015 18:34:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Johannes Ott CC: PHP Developers Mailing List 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> In-Reply-To: <57.60.52108.BE854055@pb1.pair.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] static constructor From: cryptocompress@googlemail.com (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.