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.coll...@gmail.com
>> <mailto:rowan.coll...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
