Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84660
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.22 as permitted sender)
Message-ID: <55023052.40100@gmx.de>
Date: Fri, 13 Mar 2015 01:33:22 +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 <mail@deroetzi.de>, internals@lists.php.net
References: <6D.2C.32765.10EC0055@pb1.pair.com>	<5500D967.5040800@gmail.com> <CAFMT4NqLaj6G2P9W0dhYc50yt27mmNP1vE+A=c_nYSqTotncUQ@mail.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> <B9.68.24603.1F222055@pb1.pair.com>
In-Reply-To: <B9.68.24603.1F222055@pb1.pair.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] static constructor
From: cmbecker69@gmx.de (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();
  }

> 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.

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] <https://wiki.php.net/rfc/howto>
[2] <https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process>

-- 
Christoph M. Becker