Johannes Ott wrote on 12/03/2015 17:05:
Am 12.03.2015 um 16:57 schrieb Rowan Collins:
Johannes Ott wrote on 12/03/2015 14:51:
That is nearly like initializing a class constant, but in my opinion a
constant should not have a "complex" algorithm (For example conditions
or read from filesystem). That should be encapsulated inside a proper
method body.
I agree, but as such, I think that method should be called somewhere by
the code, even if only by a DI container, not happen automagically and
slurp in data from global state.
It is called somewhere in the code namely inside the static constructor :D
What I meant is that it is not executed by any piece of code the user
writes, but directly by the engine based on a magic hook.
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.
Incidentally, note that a recent RFC to add the ability to declare a
class as static failed by 12 votes to 5 -
https://wiki.php.net/rfc/abstract_final_class - and much of the
discussion was around static implementations being generally inferior to
instances, so I'm not alone in challenging designs that rely on them.
I will check the rfc later but "static class" sounds strange.
Basically, all your examples imply classes that consist only of static
members - they're not using static helpers to create instances, they're
using them *instead of* instances. This was what was mean by "static
class" in that proposal. Personally, I was in favour of that, since I
think such classes do exist, and a syntax for declaring them would be
useful, but the most common argument against was that we should be
finding ways for people to not need such classes, rather than supporting
them better. This proposal sounds like it's adding facilities to classes
that belong on objects, or ... somewhere else.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
