rfc:static_class

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:static_class [2024/07/13 12:58] – bilgerfc:static_class [2024/08/10 13:30] (current) – bilge
Line 3: Line 3:
   * Date: 2024-06-23   * Date: 2024-06-23
   * Author: Paul Morris <bilge@scriptfusion.com>   * Author: Paul Morris <bilge@scriptfusion.com>
-  * Status: Under Discussion+  * Status: Declined
   * Target Version: PHP 8.4   * Target Version: PHP 8.4
   * Implementation: https://github.com/php/php-src/pull/14861   * Implementation: https://github.com/php/php-src/pull/14861
Line 16: Line 16:
   * Language-level runtime checks to verify the class is never instantiated by any mechanism.   * Language-level runtime checks to verify the class is never instantiated by any mechanism.
  
-Of these advantages, the first can be somewhat mitigated with a [[https://github.com/ScriptFUSION/StaticClass/blob/master/src/StaticClass.php|userland trait]], but as such traits are non-standard, there is no consistent way to identify them between projects. Moreover, the language-level checks cannot be so easily satisfied, thus are better suited for inclusion in PHP.+Of these advantages, the first can be somewhat mitigated with a [[https://github.com/ScriptFUSION/StaticClass/blob/master/src/StaticClass.php|userland trait]], but as such traits are non-standard, there is no consistent way to identify them between projects. The ''static'' keyword is a consistent way to identify static classes that could also be leveraged by static analysis and code-completion tooling. Equally importantly, the language-level checks cannot be replicated in userland, thus are better suited for inclusion in PHP. In particular, classes with a private constructor can still be instantiated via reflection and faux-deserialization hacks.
  
 ===== Proposal ===== ===== Proposal =====
Line 26: Line 26:
 </code> </code>
  
-We introduce the ''static'' keyword at the class level to preclude the need to create a private constructor. That is, ''function %%__%%construct()'' is a compile-time error in a static class. Furthermore, attempting to instantiate a static by any means, whether with the ''new'' keyword, ''ReflectionClass::newInstance*'' methods or ''unserialize()'' hacks, is strictly forbidden and will result in a runtime error.+We introduce the ''static'' keyword at the class level to preclude the need to create a private constructor. That is, <php>function __construct()</php> is a compile-time error in a static class. Furthermore, attempting to instantiate a static by any means, whether with the ''new'' keyword, <php>ReflectionClass::newInstance*</php> methods or <php>unserialize()</php> hacks, is strictly forbidden and will result in a runtime error.
  
 Whilst the goals of this RFC so expressed are fairly straightforward, we acknowledge there are many finer points to consider. In particular: Whilst the goals of this RFC so expressed are fairly straightforward, we acknowledge there are many finer points to consider. In particular:
Line 48: Line 48:
   - A static class may use traits, provided they introduce no instance members.   - A static class may use traits, provided they introduce no instance members.
   - A static class may be marked abstract, since abstract static functions already exist in PHP.   - A static class may be marked abstract, since abstract static functions already exist in PHP.
-  - All static magic methods must be supported, i.e. just ''%%__%%callStatic()''.+  - All static magic methods must be supported, i.e. just <php>__callStatic()</php>.
  
 ==== Static keyword for class members ==== ==== Static keyword for class members ====
Line 78: Line 78:
 ==== Reflection extensions ==== ==== Reflection extensions ====
  
-A new ''ReflectionClass::isStatic'' method should be added, returning ''true'' when the class is so marked, otherwise ''false''.+A new <php>ReflectionClass::isStatic</php> method will be added, returning ''true'' when the class is so marked, otherwise ''false''.
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 85: Line 85:
  
 ===== Future Scope ===== ===== Future Scope =====
 +
 +These are some possible future extensions, but we don't necessarily endorse them.
  
   - As noted in [[readonly_properties_v2#restrictions|Readonly properties 2.0]], read-only static properties are not supported due to a technical limitation. If that limitation should ever be lifted, we could revisit lifting the restriction on mutual exclusivity with the ''readonly'' modifier.   - As noted in [[readonly_properties_v2#restrictions|Readonly properties 2.0]], read-only static properties are not supported due to a technical limitation. If that limitation should ever be lifted, we could revisit lifting the restriction on mutual exclusivity with the ''readonly'' modifier.
   - Static interfaces may be introduced later if there is such a demand.   - Static interfaces may be introduced later if there is such a demand.
   - Static traits may be introduced later if there is such a demand.   - Static traits may be introduced later if there is such a demand.
- 
-This author has no intention to pursue any of these possible extensions at this time. 
  
 ===== Vote ===== ===== Vote =====
Line 96: Line 96:
 As per the [[RFC/voting#required_majority|voting RFC]] a yes/no vote with a 2/3 majority is needed for this proposal to be accepted. As per the [[RFC/voting#required_majority|voting RFC]] a yes/no vote with a 2/3 majority is needed for this proposal to be accepted.
  
-Voting started on 2024-07-XX and will end on 2024-XX-XX.+Voting started on 2024-07-15 and ended on 2024-08-09 at 21:00 UTC.
  
-<doodle title="Static class" auth="bilge" voteType="single" closed="false" closeon="2022-01-01T00:00:00Z">+<doodle title="Implement static classes as described?" auth="bilge" voteType="single" closed="false" closeon="2024-08-09T21:00:00Z">
    * Yes    * Yes
    * No    * No
Line 105: Line 105:
 ===== Discussion ===== ===== Discussion =====
  
-Though this is a fairly straightforward RFC, it is not without its detractors. Some view static classes, even without any state, as an anti-pattern; just a namespace cheat that should instead be presented as namespaced functions (sans-class wrapper). That goes double for static classes including state, where static properties can be viewed as equivalent to global state, which is widely regarded as an anti-pattern. However, this RFC is //not// encouraging any particular patterns. On the contrary, we are merely returning a small but nevertheless useful tool to the developer's toolkit that could have been available since classes were introduced. In this humble author's opinion, static classes //should// just be a collection of pure functions, but as defined by our opening razor, we will //not// remove features from a static class that exist in a non-static class because we do not have the liberty of designing a new language, we're designing PHP, with all the weight of its past carried forward. Anyone wishing to remove features from PHP can submit a separate RFC, or perhaps more practically, just add a check to their favourite code style tool.+Though this is a fairly straightforward RFC, it is not without its detractors. Some view static classes as an anti-pattern; a namespace cheat that should instead be presented as namespaced functions (sans-class wrapper). That goes double for static classes including state, where static properties can be viewed as equivalent to global state, which is widely regarded as an anti-pattern. However, this RFC is //not// encouraging any particular patterns. On the contrary, we are merely returning a small but nevertheless useful tool to the developer's toolkit that could have been available since classes were introduced. In this humble author's opinion, static classes //should// just be a collection of pure functions, but as defined by our opening razor, we will //not// remove features from a static class that exist in a non-static class because we do not have the liberty of designing a new language, we're designing PHP, with all the weight of its past carried forward. Anyone wishing to remove features from PHP can submit a separate RFC, or perhaps more practically, just add a check to their favourite code style tool.
  
-Some regard namespaced functions as the correct way to implement static classes. That is, a file of floating functions under a namespace, as in [[https://github.com/amphp/amp/blob/138801fb68cfc9c329da8a7b39d01ce7291ee4b0/src/functions.php|Amp]]. This author requested comments that would speak to any technical or philosophical reason for why this would be strictly better than a static class, but the only technical argument fielded was that classes can be autoloaded and functions cannot. Curiously, this fact only speaks //in favour// of static classes. One might argue this difference is negligible thanks to Composer; files of functions can be loaded by Composer, but in this case the file is //always// loaded, not //auto//loaded. Still, this could be splitting hairs since opcache presumably trivializes this difference. Interestingly, the current Amp maintainers commented that namespaced functions were something they inherited, and if they had to do it all over again, would probably elect for static classes. The conclusion seems to be that those preferring one style over the other do so purely out of personal preference and not because one is technically nor even philosophically superior.+Some regard namespaced functions as the correct way to implement static classes. That is, a file of floating functions under a namespace, as in [[https://github.com/amphp/amp/blob/138801fb68cfc9c329da8a7b39d01ce7291ee4b0/src/functions.php|Amp]]. This author requested comments that would speak to any technical or philosophical reason for why this would be strictly better than a static class, but the only technical argument fielded was that classes can be autoloaded and functions cannot. Curiously, this fact only speaks //in favour// of static classes. One might argue this difference is negligible thanks to Composer; files of functions can be loaded by Composer, but in this case the file is //always// loaded, not //auto//loaded. Still, this could be splitting hairs since opcache presumably trivializes this difference. Interestingly, the current Amp maintainers commented that namespaced functions were something they inherited, and if they had to do it all over again, would probably elect for static classes. Thus we conclude those preferring one style over the other do so purely out of personal preference and not because one is technically nor even philosophically superior. 
 + 
 +Most importantly, this proposal does nothing to promote any patterns or practices not already possible, nor does it block or inhibit development of orthogonal approaches, such as autoloading of namespaced functions, which some may regard as equivalent.
  
 ===== In the wild ===== ===== In the wild =====
 +
 Today, implicit static classes are all around us, in proprietary projects and some of the largest open source projects in the world, often called //utils// or //helpers//, all of these classes would benefit from being explicitly marked static. To name a few: Today, implicit static classes are all around us, in proprietary projects and some of the largest open source projects in the world, often called //utils// or //helpers//, all of these classes would benefit from being explicitly marked static. To name a few:
  
Line 133: Line 136:
  
 ===== References ===== ===== References =====
 +
 +  * Discussion threads
 +    * [[https://externals.io/message/123769|This RFC]] (Bilge, June 23, 2024).
 +    * [[https://externals.io/message/123611|Initial proposal]] (Bilge, June 15, 2024).
 +    * [[https://externals.io/message/121717|Prior proposal]] (Lanre Waju, November 19, 2023).
 +  * Archaic discussion threads
 +    * [[https://externals.io/message/79601|[VOTE] Abstract final / Static classes]] (Guilherme Blanco, December 12, 2014)
 +    * [[https://externals.io/message/79338|[RFC] Static classes (Was Abstract final classes)]] (Robert Stoll, December 1, 2014)
 +    * [[https://externals.io/message/79211|[RFC] Abstract final classes]] (Guilherme Blanco, November 27, 2014)
 +  * Similar RFCs
 +    * [[rfc/abstract_final_class|RFC: Static classes]] (Guilherme Blanco, November 26, 2014)
 +    * [[rfc/static-classes|RFC: Static classes for PHP]] (Lars Strojny, May 3, 2008)
  
   * [[https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/static-classes-and-static-class-members|Static Classes and Static Class Members (C# Programming Guide)]]   * [[https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/static-classes-and-static-class-members|Static Classes and Static Class Members (C# Programming Guide)]]
rfc/static_class.1720875519.txt.gz · Last modified: 2024/07/13 12:58 by bilge

Page Tools