Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85808
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <53.B5.47925.6D05D255@pb1.pair.com>
To: internals@lists.php.net
Date: Tue, 14 Apr 2015 19:39:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
References: <CB.90.41712.5B6CB255@pb1.pair.com> <CA+kxMuT9tB_xeYot-TAu=ZXphcQpsTrezbjsz0iAPiUhCsgWTQ@mail.gmail.com>
In-Reply-To: <CA+kxMuT9tB_xeYot-TAu=ZXphcQpsTrezbjsz0iAPiUhCsgWTQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] New RFC draft "static class constructor"
From: mail@deroetzi.de (Johannes Ott)

Am 14.04.2015 um 16:33 schrieb Dan Ackroyd:

> Here is some feedback then:
> 
> From the RFC:
>> - Trigger for “magic” method call: First call to class, either first call to __construct(...) or first call to any public or protected static method or property of the class
> 
> I don't think this doesn't cover all cases that it needs to. For
> example calling unserialze on some data that results in a class that
> has this static initializer should mean that it would be invoked?
> Similarly ReflectionClass::newInstanceWithoutConstructor also creates
> a class in a way that isn't covered in the RFC, but presumably should
> be.
> 

Your correct I forgot this two scenarios of first calls to a class.
Thanks for the hint!

But in the new draft (v0.4) I'm preparing at the moment I'll try to
formulate the trigger "first call" more common by comparing it to the
same trigger for __autoload function. Then these two scenarios should be
included as well.

> From the RFC.
>> the static class constructor should be able to throw a catchable Exception
>> for user error handling, if it is not possible to initialize. The open issue for
>> me is, what the behavior on recalling the static class constructor afterward is.
>> There are two possible behaviors I do not know which one I really would prefer so far.
> 
> You missed the third and in my opinion correct one; the static
> initializer would only ever be called once. 

I think this is suggested behaviour 1, isn't it?

"On recall of the static class constructor a fatal error is raised to
ensure it is only called once..."

>If the programmer catches
> the exception and forces the program to continue, that is their own
> problem. Adding complexity to a language to try to work around
> programmers ignoring exceptions is not a good idea.
> 

I agree to this point that ignoring an exception is a bad idea. I think
the example-code is a bit confusing, because the empty catch-block gives
the impression that the exception is ignored. But what is really meant
by behaviour 2 is that the programmer has the opportunity to handle the
exception not by exiting his programm, but by cleaning up the
situation and afterwards retry the code which failed before.

I will try to clearify this in one of the next draft versions.


> I think the RFC needs to be clearer in the specification of the order
> that static initialization is called in. e.g. class B extends class A.
> Both A and B have static initialization blocks. When a user calls `new
> B()` which static initialization block is called first?
> 

While rewriting the draft for v0.4 I although noticed this gap inside
specification and came to the conclusion that this is the third "first
call" scenario I haved missed. Because inheritance by using keyword
extends is already a first call to class A.

> cheers
> Dan
> 

Thanks for really constructive feedback, that one really helps me for
the next draft of rfc

Regards

-- 
DerOetzi