|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #47971 Allow 'static' keyword to be applied to entire classes
Submitted: 2009-04-14 21:07 UTC Modified: 2018-01-11 17:08 UTC
Avg. Score:3.7 ± 1.7
Reproduced:5 of 6 (83.3%)
Same Version:3 (60.0%)
Same OS:3 (60.0%)
From: cscott at ggot dot org Assigned:
Status: Suspended Package: Class/Object related
PHP Version: * OS: *
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: cscott at ggot dot org
New email:
PHP Version: OS:


 [2009-04-14 21:07 UTC] cscott at ggot dot org
Fairly simple: A developer is allowed to define his/her classes as abstract or final, but not as static.  For continuity's sake, it would be preferable to be able to declare classes as static as well.  This would greatly ease the creation of static function collections/libraries, especially those included with __autoload().

When a class is declared as abstract, it is a statement at the open that this is an incomplete member; you can specify any method inside a class to be abstract and the class is effectively abstract, yet this keyword is allowed in the class declaration.

When a class is declared final, it is a statement at the open that all members are to be considered final, and that this class should not be extended any further.

By allowing classes to be declared as static, it would follow with allowing "abstract class foo" in the sense that the keyword reflects the contents of the class, and would follow with "final class foo" in that it would define a binding construct for all members of the class.

a) In a static class, all methods and members are automatically static
b) In a static class, all methods and members must be declared static
Is surely not for me to decide -- either is useful, as it either forces me to ensure all members are static, or it does the legwork for me.  As such, I make no suggestion and defer to the wisdom of the developer(s).

Thank you for your consideration.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-10-31 00:27 UTC] cscott at ggot dot org
For Relevancy: I do not believe that namespaces solve this problem, as 
__autoload does not work with namespaces (and, for obvious reasons, 
 [2010-12-20 08:43 UTC]
-Package: Feature/Change Request +Package: Class/Object related -Operating System: Irrelevant +Operating System: * -PHP Version: 5.2.9 +PHP Version: *
 [2012-10-26 16:09 UTC] dagguh at gmail dot com
What you are referring to is a utility class.
It only has static members and a private constructor, which should never be 
called (even from the class itself).

Your suggestion could be useful, because implementing private empty constructors 
is just boilerplate code.
PS. Some people even throw an exception inside the private constructor.
 [2012-12-18 05:57 UTC] phpmpan at mpan dot pl
One note:
PHP allows calling static methods on class instances and this actually works faster* than pure static call. Compare:

for (... many times ...) {


$instance = new UtilityClass();
for (... many times ...) {

Creating an instance of a utility class is a neat optimization in heavy loops.

Do not consider me an advocate of premature optimization, but if g*to was introduced in PHP because generated code may benefit from it, ability to create instances of utility classes should not be prohibited for the same reason. If OP's proposition is implemented, people will flock to it, effectively blocking ability to use the described solution.

* 25% less time consumed; tests were performed about a year ago
 [2013-09-19 22:17 UTC] metamarkers at gmail dot com
I think what you're describing is a "final abstract" class, which has been 
suggested I think, though I can't find it in the requests.

So make an abstract class and use a trait to pull in an empty final private 
constructor that triggers an E_USER_ERROR. But this is fighting with the 
developer, and adds an unnecessary layer. The developer will always win. People 
are free to throw a wrench into their own machinery if they want. 

The flavor of the class should have no bearing on the default scope of its 
members. Members need to be declared as the scope they should have. What you're 
suggesting also implies we should be able to make protected and private classes 
(in the global scope).

I'm in support of "final abstract" / "static" classes. Doesn't seem to be a 
reason to disallow this. Some kind of declaration that says "this class is 
inert, you can't instantiate it".
 [2013-09-19 22:23 UTC] metamarkers at gmail dot com
Just a quick addendum, "final abstract" would disallow inheritance, which is what 
abstract classes are for. So "static"/"final static" would be cool.
 [2018-01-11 17:08 UTC]
-Status: Open +Status: Suspended
 [2018-01-11 17:08 UTC]
This feature request requires the RFC process[1], so I'm
suspending this ticket in the meantime.

[1] <>
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Apr 14 20:01:30 2024 UTC