Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84687
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <2D.57.32208.DD303055@pb1.pair.com>
To: internals@lists.php.net
Date: Fri, 13 Mar 2015 16:35:54 +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> <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> <55023052.40100@gmx.de> <7B.3E.24603.E83B2055@pb1.pair.com> <5502CFB4.7080406@gmail.com> <5502E7D6.50909@gmail.com>
In-Reply-To: <5502E7D6.50909@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] static constructor
From: mail@deroetzi.de (Johannes Ott)

Am 13.03.2015 um 14:36 schrieb Rowan Collins:
> 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.
>
I agree with this statement only a bit because it makes static context
obsolete: real *states* belong to instances, no doubt about this. The
logger state for example as LogAdapter is a Singleton-Factory is still
inside the singleton instance and in this case only a new reference to
the class specific instance is stored as kind of "shortcut" for less
code and maybe little bit of performance to the class itself. That is
although the DI-pattern on runtime, but in static class context.

But anyway a class having any kind of static property inside is stateful
by definition of static. The best example is already each
singleton-class, it has the state initialized or not intialized. That is
the basic concept of static-context at all, the only stateless things
inside class context are class-constants.

Or another example the posted ConfigFile-Wrapper, what is the sense of
wrapping another level arround by doing it with a singleton instance.
The class itself by its definition already represents the state of
config.ini-File that will not change during the current runtime because
it is global *data*. In my opinion there is absolutely no sense beside
the effect that I have more code to write and especially to read.

As conclusion as long as there is this static, stateful class context
each coder can decide at everytime which static properties he sets to
define the state of the class, as a good programmer you should be aware
to use this careful, but that has absolutley nothing todo with the
proposed RFC.

But while you have already for instances a defined language method
called __construct to set the inital state of an instance, there is no
such language method to set the initial state of the class, which would
be the __static(); In my opinion this would even help beginners to
understand how careful they have to be with static context, because they
are doing something inside a special "magic" method.

BTW even the singleton pattern could have a slightly better performance
with this feature, if you do not have the need of parameters to the
instance constructor code can look like this:

abstract class Singleton() {

    private static $instance;

    private static function __static() {
        self::$instance = new Object();
    }

    public static function getInstance() {
       return self::$instance;
    }

}


> 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,


I think as Christoph wrote we should now do a cut here for the inital
discussion, because we are in a circle now. I will now get on at the RFC
process, and will prepare the RFC-draft asap.

I will try to summarize as good as possible all discussion points we had
the last days here. And I will try to figure out as clearly as possible
how each point really touchs the purpose of the new requested language
feature or is a general problem if you use static context a "wrong" way,
although outside the static constructor.

I want to say thank you especially to you Rowan, for the so far very
good discussion, which gives a lot of input to me for writting the RFC.

Regards,
-- 
DerOetzi