Sorry, replying to myself to add a couple of thoughts / clarifications:
Rowan Collins wrote on 13/03/2015 11:53:
Johannes Ott wrote on 13/03/2015 09:53:
Why are in your opinion static members are not allowed to hold more
complexe datastructures then simple scalars?
Complex data structures, yes (and I see the use of __static in such
cases). Architectural logic gluing one class to another (as in your
Logger example), no.
I think I've come up with a better distinction: *state* belongs in
instances, whereas *data* can exist globally. A logger object
encapsulates state, so a pointer to one is stateful information; storing
that state statically is what feels wrong.
A singleton in this case says "there is a bunch of stateful information
here, but everywhere *in the current code* needs the same instance of it".
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.
You don't need to double all the calls. In fact, the majority of your
code should not even know the Singleton is there, because they should
be treating it as though they have an instance. At certain key points
in your code (constructors, the top of methods) you add $foo =
Foo::getInstance();, then all your calls look like $foo->doBar();
That's the way I do it, anyway - treat getting the instance for a
singleton like importing a variable from global scope, which is
basically what it's doing.
In other words, saying "Foo::getInstance()->bar();" is like using
"$GLOBALS['foo']->bar();" saying "$foo = Foo::getInstance();
$foo->bar();" is like saying "global $foo; $foo->bar();"
The act of retrieving the singleton is separate from the act of using it.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
