Am 13.03.2015 um 11:30 schrieb Johannes Ott:
Am 13.03.2015 um 07:45 schrieb Crypto Compress:
Hello Johannes,
in other mails you argue with Rowan about global state. I think it's
better to focus on innovation of "class context" in global scope, as
it's impossible to reason the disadvantages of global state away.
(Discussions on variable scope are painful too.)
And two questions:
1. By definition cctor is guaranteed to be executed only once. Right?
Yes as the __static should be as well. See discussion with Rowan and
Patrick for details.
As I already told, I still have to clearify howto react if an exception
occurs inside the static class constructor. I prefer at the moment the
variant that a second try will raise a fatal error. But I will think
about this before I'll prepare the RFC.
2. In your examples you employ some external resources in cctor (e.g.
logger, db, ini-files). Do you intend to propose a cdtor to release this
resources?
For my understanding the lifecycle of a class is from the loading of the
class definition to the end of the application or until some explicit
class unload (don't know whether php has such feature).
PHP has no explicit class domain unload feature and you do not plan to
implement this. Okay.
If loading a
instance to a static member you must be aware that this instance will
live till the end of lifetime of the class (that is the basic of
static). But at the end I hope PHP is unsetting all static members as
well, which should trigger the destructor of this instance as well.
If PHP is not reacting like this (but I'm sure it is because without all
suggested singletons here would be a huge memory and connection leak as
well), I know what my second rfc would be :D
Second point if you open a resource to read some data inside a method
and do not assure that it is closed again either explicit inside the
method or on a global pattern (for example my DBAdapter I use to read,
holds a single connection to database which is closed at the very end of
run), this would be poor code inside the static constructor as well as
it would be inside every other method.
This "poor code inside the static constructor" seems to be a crucial
point of your RFC.
So I do not see the need of a explicit class deconstructor, because the
language should already react correctly on this issues as I can see so far
The language cannot know the order of dependencies and how to destruct them.
Regards,
Thank you!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
