Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84672 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 83668 invoked from network); 13 Mar 2015 09:53:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Mar 2015 09:53:20 -0000 X-Host-Fingerprint: 194.166.179.101 194-166-179-101.adsl.highway.telekom.at Received: from [194.166.179.101] ([194.166.179.101:8736] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7B/3E-24603-E83B2055 for ; Fri, 13 Mar 2015 04:53:19 -0500 Message-ID: <7B.3E.24603.E83B2055@pb1.pair.com> To: internals@lists.php.net Date: Fri, 13 Mar 2015 10:53:14 +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> <55023052.40100@gmx.de> In-Reply-To: <55023052.40100@gmx.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Posted-By: 194.166.179.101 Subject: Re: [PHP-DEV] static constructor From: mail@deroetzi.de (Johannes Ott) Am 13.03.2015 um 01:33 schrieb Christoph Becker: > Johannes Ott wrote: > >> And i although see no DI or Singleton pattern to use here to get the >> same functionality, if you want to use like Config::getHostname() and >> not like Config::getInstance()->getHostname() which is really >> unnecessary abstraction level for nothing in my opinion! > > It is possible, however, to add static wrapper methods to access the > singleton's methods, like > > public static function getHostname() { > return self::getInstance()->_getHostname(); > } > I really do not understand why everybody here seems to try to use Singleton where ever it is possible. Indeed Singletons are a nice Design Pattern, but they are no universal remedy for every problem just for the fact you can use it there as well. Why are in your opinion static members are not allowed to hold more complexe datastructures then simple scalars? Please give me one valid argument why I should double all of the functions in my code for a static and non-static access beside the argument that I "have to" use a Singleton. As I already said this is a abstraction level that makes absolutly no sense. >> It is not only about the extra method-call but although the additional >> Null check inside this method call. >> >> Let's do some calculation for that: in average I have 5 calls of the >> logger per method the message is used 10 times during the programm. >> Now we already have 49 unnecessary method calls (with all needed to do >> for the interpreter like preparing stack, copying the returns etc.) and >> 40 unnecassary null checks inside (as we agreed before that is not >> counted fully, because the evaluation of the flag will although take >> some time but can be more efficient inside the interpreter). Let's now >> think only about 10 such methods we are already at a count of 490 >> unnecessary method calls. Maybe only slightly worse performance but it >> is a performance issue! And there is this very old performance rule: a >> lot of small performance issues can become quickly to a huge one. >> >> I have counted the calls in code of self::$LOG-> inside one small >> private webproject of mine with less logging implemented yet. But there >> are already 128 calls. If you multiply by 10 you already have 1280 calls >> on runtime, I think that is a performance issue. > > It seems to me that the logger example is not appropriate to show > performance penalties due to unnecessary method calls and null checks, > because the actual task of the logger (write to a file/database, or even > send an email) is easily much more demanding performance-wise. This depends on the log-level lot of the calls are debug and traces which are not active in production enviroment. Only a few of them are info, warn or error. But you are right it isn't a perfect example for benchmark the current idea, but as a whole I'm sure to have a slightly performance improvment with this static constructor as well. But anywhere performance was not the main matter of concern of this proposal, but to make the possibility to write cleaner code with less lines. > > Anyhow, in my humble opionion, there had been enough initial discussion > on this idea, and it would be reasonable to proceed with the actual RFC. > See "How To Create an RFC"[1] and especially "The Mysterious PHP RFC > Process and How You Can Change the Web"[2]. :) > > [1] > [2] > Okay thanks for the hint I will prepare the rfc on weekend then. BTW for me haven't done c- programming for a long time it would be a joy if someone who has mor experience with PHP-core would help to implement the RFC if it will be voted positive. Or even give me some hints to the structure of the core where to start this. Already did some research on that and I'm thinking somewhere zend_object_handler.c but not sure about this. Thanks in advantage to all for the in my opinion good discussion so far about this issue. Gave me some good hints, where I have to have a closer look, when writing the RFC now. Regards -- DerOetzi