static constructor

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" <rowan.collins@gmail.com
mailto:rowan.collins@gmail.com>:

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

Am 12.03.2015 um 21:33 schrieb Rowan Collins:

Johannes Ott wrote on 12/03/2015 19:45:

All of the magic methods are doing like this.

I thought you might say that, but the only thing remotely similar I can
think of is a destructor, which gets called when an object goes out of
scope; the others are all the implementation of, or instead of, some
specific piece of code:
__construct() runs every time for new Foo
__get() and __set() runs every time for property access with -> on an
undefined property
__call() and __callStatic() runs every time for method access on an
undefined property

The difference with this is that you never know which part of your code
will actually trigger it, because it only runs some of the time.

I cannot see any difference because the trigger is defined really clear
for each of the functions

For Example Class Foo implements all of those functions the triggers
would be

__construct -> triggered each time I write "new Foo()"

__destruct -> triggered each time a instance loses his last reference
and is removed by garbage collection.

__get() and __set() -> triggered each time I try to access a property
of my foo instance which is not accessible (not defined or private) from
outside Foo writing $foo->notfromoutside

__call() -> triggered each time I try to call a non-static method on a
instance of Foo which is not accessible from outside writing
$foo->notfromoutside()

__callStatic() -> triggered each time I try to access static method of
the class which is not accessible from outside writing Foo::notfromoutside()

And finally the proposed new one

__static() -> triggered on the first time I write either "new Foo()" or
"Foo::eachStaticPublicOrProtectedMethodOrProperty()"

I really don't see what __static() has more "magic" or unclear trigger
then each of the other so called magic methods?!

Do keep away any doubt, in my opinion none of the so called magic
methods have any kind of magic. They are just language patterns you
should understand how they work before you start to use them in your
code! So "private static function __static() {...}" is just another
pattern you have to understand before you use. If you don't understand
how it works you should not use. That is the same for all language
patterns and elements, for example: loops, conditions, scalar-operators,
etc.

And as I already told a static class constructor is a kind of well-known
standard function in mostly all modern OOP-languages. So professional
OOP-developer should be or become very fast familiar with this pattern.

Okay thats a point I have to clearify I see, maybe my examples where to
much shorten by me. In my examples I'm showing only the initialize parts
of the classes, the initialized properties are used all over the class
in static as well in non-static context.

OK, so these are classes which share certain resources between all
instances, represented by these static properties. In that case, would
it be reasonable to say that the initialization of these properties
needs to happen the first time an instance is created? If so, the
if(self::$initialized) check needs to run only as often as
__construct(), not every time any method is called.

If you look closer at my example you will see, that the property is not
just shared between instances (then the normal constructor Could be
indeed be the place to initialize), but it is shared although with
different static methods inside the class.

If the static methods are public, and used for something other than
managing instances (Factory / Singleton / etc), then are they really the
responsibility of the same class? i.e. do you have a Utility class
hiding in there pretending to be part of the instance/factory class?

See my example 2 for a Config Wrapper class:

abstract class Config {
private static $arIni;

private static function __static() {
    self::$arIni = parse_ini_file('config.ini');

    //For example check whether all required fields are in the file

or throw Exception if not.
}

public static function `getHostname()` {
    return self::$arIni['hostname'];
}

public static function getDBConnectionString() {
    return ' self::$arIni['dbdriver'] . '://' .

self::$arIni['dbuser'] . '@' .self::$arIni['dbhost'] ...;
}

...

}

The Config class is in response for all config Parameters inside
config.ini and needs to read in this file before it can to it's work
correctly. No hiding of Factory/Singleton/instance in this.

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!

For use case 1 the LogAdapter for example is a singleton instance per
class, that's why in my understanding of dependcy Injection it is not
working with it (correct me please if I'm wrong). And this singleton is
used to log in all methods of the class/object.

In a system using Dependency Injection, all dependencies have to be
passed in somewhere; a static dependency could be injected into a static
property by a static method, but it still has to come from somewhere.
Your implementation is pulling it from a global variable (or a public
static, which is effectively the same thing) rather than waiting for it
to be provided.

Note also that you don't need to create 5 loggers just because you have
5 objects needing a logger - you pass in (or acquire from a global
variable) references to the same instance each time - so the fact that
it's an instance property rather than a static one is really no hardship.

public function __construct() {
$this->logger = LogAdapter::getLogger(self::class);
}

As I said above, if I only use in instance context I agree with the
normal constructor.

Surely I would be able to get the specializied Singleton instance with
doing some code like the following two examples:
[examples trimmed]

If not using any injection, I would implement it as follows:

class A {

private static $LOG;

private static function getLogger() {
if (self::$LOG = null) {
self::$LOG = LogAdapter::getLogger(self::class);
}
return self::$LOG;
}

public static function a() {
self::getLogger()->debug();
....
self::getLogger()->error();
}

public function b() {
...
self::getLogger()->error();
}

...

}

Not much more verbose than your version with __static, but a lot less
magic, and therefore easier to debug. Slightly worse performance, with
the extra method call, but I doubt if it would add up to enough to worry
about.

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.

Thinking about it, you could even leave the way open for a different
strategy by using $this->getLogger() instead of self::getLogger() -
right now, that's 100% equivalent, but it makes it easier to change
later to use injection, or be able to override the logger on particular
instances, etc.

Sorry I'm confused now after reading this sentence and I have to ask
now, because I'm not sure anymore, whether you really have understand
the difference between static and non-static context and the inheritance
of classes inside PHP, especially the difference between $this, static,
self?

How can $this->getLogger() be equivalent to self::getLogger();

First contra Example:

class A {

private function getLoggerNonStatic() {
    echo 'A->getLoggerNonStatic';
}

private static function getLoggerStatic() {
echo 'A::getLoggerStatic';
}

public static function call() {
    $this->getLogger();
}

public static function call2() {
    self::getLogger();
}

}

A::call() //Fatal error $this in static context?
A::call2() //Output A::getLoggerStatic;

Second contra Example:

class A {

protected function getLoggerNonStatic() {
    echo 'A->getLoggerNonStatic()';
}

protected function getLoggerStatic() {
    echo 'A::getLoggerStatic';
}

public function call() {
    $this->getLoggerNonStatic();
    self::getLoggerStatic();
    static::getLoggerStatic();
}

}

class B extends A {

protected function getLoggerNonStatic() {
    echo 'B->getLoggerNonStatic()';
}

protected function getLoggerStatic() {
    echo 'B::getLoggerStatic';
}

}

$b = new B();
$b->call();

Output:
B->getLoggerNonStatic();
A::getLoggerStatic();
B::getLoggerStatic();

As you can see line 1 and 2 of the output not equivalent even by class,
but I want to log functionality of A as functionality of A not of B!

This is often the problem with magic methods, be they at the language
level or in a framework: they tend to lock you into working in a
particular way, where more explicit code can be more readily refactored.

Beside the performance for me and for each clean coder I know (btw as a
Software Architect I'm in charge of code quality of a huge Java project
at the moment, so I think I know what I'm talking about), to read 100
times self::getLogger()->... and have to think about whether the
getLogger() method (which should be by "standard" oop-naming conventions
ONLY a three lines of code getter and nothing else) is doing the magic
of getting a instance first, is much more worse then understanding once
what a static class constructor does and then just use self::$LOG->... A
"magic" getter identified by prefix get doing anything beside giving
back a class member is really far away from clean code!

Regards,

DerOetzi