Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84656 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 25478 invoked from network); 12 Mar 2015 20:11:17 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Mar 2015 20:11:17 -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:22196] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 15/86-24603-4E2F1055 for ; Thu, 12 Mar 2015 15:11:17 -0500 Message-ID: <15.86.24603.4E2F1055@pb1.pair.com> To: internals@lists.php.net Date: Thu, 12 Mar 2015 21:11:13 +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> <5501EA37.4050905@gmail.com> In-Reply-To: <5501EA37.4050905@gmail.com> 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 12.03.2015 um 20:34 schrieb Rowan Collins: > Patrick Schaaf wrote on 12/03/2015 18:40: >> >> Am 12.03.2015 18:56 schrieb "Rowan Collins" > >: >> > >> > Johannes Ott wrote on 12/03/2015 17:05: >> > >> >>>> So doing a null check each time >> >>>> is a overhead of calculation which can be avoided with this static >> >>>> constructor pattern. >> >>> >> >>> Presumably the engine would need to perform some implicit >> equivalent of >> >>> "if ( ! self::$initialised )" on each call to decide if the static >> >>> constructor needs to be called or not, so the overhead is not >> completely >> >>> eliminated. >> >>> >> >> Yes you are right but I think it can be done more efficiently >> inside the >> >> interpreter using some struct flags then have to parse each time >> inside >> >> a coded part in the application. >> > >> > Yes, point taken. >> >> I don't think such a flag is neccessary at all. Any class. at the >> moment, comes from one or another file that is included / required. >> And all of the code in these files outside the class definition, is >> then immediately executed. The only thing neccessary would be to >> check, just before that execution begins, which of the new classes >> have such an initializer method, and then call that, before the >> execution of the file itself begins. >> > > This was my initial interpretation, but Johannes has explained that that > is not the intention of this proposal. Instead, it is intended to be > called on first *use* of the class; a subtle difference, but given this > code: > Correct! On that point I agree with Rowan, for the fact that there a lot of of libraries and application in user-land which don't use autoload function to include the classes when required, but include all classes at the startup, but on different paths through the application only use a few of them. Or in future the interpreter or a maybe application server will have some optimization which loads the classes it may need already in memory, but never use it then. The static constructor pattern should avoid overhead in all of this current and possible future cases. Instead the static constructor should behave like the following user-code: class A { private static $bInitialized = false; ... private static function init() { if (self::$bInitialized) { return; } ... self::$bInitialized = true; } public static function a() { self::init(); ... } public function b() { self::init(); ... } ... } So we need the "$bInitialized" flag in the struct. Another point already mentioned for the example where the static constructor uses database connection or something there can be a lot of unnecassary db-connections opened on creation time. Regards, -- DerOetzi