rfc:static_class_constructor

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
rfc:static_class_constructor [2015/04/13 13:21] – Initial draft v0.1 deroetzirfc:static_class_constructor [2025/04/03 13:08] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== PHP RFC: Static Class Constructor ====== ====== PHP RFC: Static Class Constructor ======
-  * Version: 0.1+  * Version: 0.2
   * Date: 2015-04-13   * Date: 2015-04-13
   * Author: Johannes Ott <mail@deroetzi.de>   * Author: Johannes Ott <mail@deroetzi.de>
-  * Status: Draft+  * Status: Inactive
   * First Published at: http://wiki.php.net/rfc/static_class_constructor   * First Published at: http://wiki.php.net/rfc/static_class_constructor
  
Line 284: Line 284:
 In this section I will try to summarize all discussion points and will try to figure out how in my personal opinion they really touch the proposal or not. In this section I will try to summarize all discussion points and will try to figure out how in my personal opinion they really touch the proposal or not.
  
-1. A argument I read several times is that within being inside the static context there could be some "crucial" things be done, for example opening and storing some resource handles to static properties, which means they couldn't be done explicit closed.+==== 1. Crucial code and complexitiy argument ==== 
 + 
 +An argument I read several times is that within being inside the static context there could be some "crucial" things be done, for example opening and storing some resource handles to static properties, which means they couldn't be done explicit closed.
  
 - First of all I used words like "crucial" or "horrific" during discussion as well, this was just to polarize inside the discussion. In my opinion there is no crucial code at all, beside the code which is not doing what programmer expected to do. There is only code, which is not as suitable for a special use case as another one would be for different reasons (less dependencies, performance, better readable code, side-effects, etc.). But this mainly depends on the special use case and should always be inside the decision of each programmer or a software architect analyzing the special use case. - First of all I used words like "crucial" or "horrific" during discussion as well, this was just to polarize inside the discussion. In my opinion there is no crucial code at all, beside the code which is not doing what programmer expected to do. There is only code, which is not as suitable for a special use case as another one would be for different reasons (less dependencies, performance, better readable code, side-effects, etc.). But this mainly depends on the special use case and should always be inside the decision of each programmer or a software architect analyzing the special use case.
Line 292: Line 294:
 - But as I am an instructor for beginners for several years I agree to the fact that the concept of static-context is one of the concepts in oop-programming which seems to be really hard to understand with all its side-effects to beginners. A suggestion, which may help is to create an extra documentation page about static context with a DOs and DONTs list on it to help everyone to get familiar with this concept. But as being a common problem of static-context I think that should not be part of this proposal. The documentation of the static class constructor can then although refer to this page. - But as I am an instructor for beginners for several years I agree to the fact that the concept of static-context is one of the concepts in oop-programming which seems to be really hard to understand with all its side-effects to beginners. A suggestion, which may help is to create an extra documentation page about static context with a DOs and DONTs list on it to help everyone to get familiar with this concept. But as being a common problem of static-context I think that should not be part of this proposal. The documentation of the static class constructor can then although refer to this page.
  
-2. Possibility of inheritance of the class constructor.+==== 2. Inheritance of the class constructor ====
  
 A class should have as less dependencies to another as possible. To give the possibility to inherit the class constructor will produce a huge amount of relationships not only between the superclass and it's subclasses but although between each subclass. For that reason this is no suitable feature of a static class constructor in my point of view.  A class should have as less dependencies to another as possible. To give the possibility to inherit the class constructor will produce a huge amount of relationships not only between the superclass and it's subclasses but although between each subclass. For that reason this is no suitable feature of a static class constructor in my point of view. 
Line 331: Line 333:
 </code> </code>
  
-3. How the error and exception handling should work?+==== 3. Error and Exception handling ====
  
 See open issues section for this topic. See open issues section for this topic.
  
-4. Need of a class destructor as well to handle unload order dependencies between classes.+==== 4. Need of a class destructor to handle unload order dependencies ====
  
 - The only order dependency between class A and class B should be an usage dependency either class B extends A or A is used static or non-static inside class B. In both cases as I can see for now, the language itself should do already everything correct by not unloading class A before class B, for doing unload by reverse creation time. - The only order dependency between class A and class B should be an usage dependency either class B extends A or A is used static or non-static inside class B. In both cases as I can see for now, the language itself should do already everything correct by not unloading class A before class B, for doing unload by reverse creation time.
Line 343: Line 345:
 - If someone can give me a suitable other example, I will think about this again. Until then this is just a possible future scope feature for me. - If someone can give me a suitable other example, I will think about this again. Until then this is just a possible future scope feature for me.
  
-5. Using explicit close feature on an example ResourcesPool class to close all opened resources (like ExamplePool::cleanupResources()) will break lazy-unloading, if class was not used before by calling the static constructor as well.+==== 5. Close method of unused ResourcesPool ==== 
 + 
 +Using explicit close feature on an example ResourcesPool class to close all opened resources (like ExamplePool::cleanupResources()) will break lazy-unloading, if class was not used before by calling the static constructor as well.
  
 - That is partly true, if called on a never used before Pool it will make an "unnecessary" call to static constructor. But on the one hand that is why I would use this feature only on pool-classes I surely know that they are used mostly on each page for example DatabaseConnectionPool. On the other hand it may be even necessary to call the static constructor to initialize some static properties necessary for the unload. - That is partly true, if called on a never used before Pool it will make an "unnecessary" call to static constructor. But on the one hand that is why I would use this feature only on pool-classes I surely know that they are used mostly on each page for example DatabaseConnectionPool. On the other hand it may be even necessary to call the static constructor to initialize some static properties necessary for the unload.
Line 349: Line 353:
 - And for still being inside the user-code phase and not in the shutdown phase of the run nothing will break, by this "unnecessary" call. - And for still being inside the user-code phase and not in the shutdown phase of the run nothing will break, by this "unnecessary" call.
  
-6. Everywhere you have to store a state of something you should use an instance instead of a class, by using for example a singleton pattern.+==== 6. Stateful things should be handled in instance not in class ==== 
 + 
 +Everywhere you have to store a state of something you should use an instance instead of a class, by using for example a singleton pattern.
  
 - As I already tried to explain in introduction section the static properties are the state of the class. If the explained pattern always would be true the static context would be obsolete. - As I already tried to explain in introduction section the static properties are the state of the class. If the explained pattern always would be true the static context would be obsolete.
rfc/static_class_constructor.1428931310.txt.gz · Last modified: 2025/04/03 13:08 (external edit)

Page Tools