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] <https://wiki.php.net/rfc/howto>
> [2] <https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process>
>
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
