Req #47971 [Opn->Sus]: Allow 'static' keyword to be applied to entire classes
Edit report at https://bugs.php.net/bug.php?id=47971&edit=1
ID: 47971
Updated by: cmb@php.net
Reported by: cscott at ggot dot org
Summary: Allow 'static' keyword to be applied to entire
classes
-Status: Open
+Status: Suspended
Type: Feature/Change Request
Package: Class/Object related
Operating System: *
PHP Version: *
Block user comment: N
Private report: N
New Comment:
This feature request requires the RFC process[1], so I'm
suspending this ticket in the meantime.
[1] <https://wiki.php.net/rfc/howto>
Previous Comments:
------------------------------------------------------------------------
[2013-09-19 22:23:03] 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.
------------------------------------------------------------------------
[2013-09-19 22:17:52] 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".
------------------------------------------------------------------------
[2012-12-18 05:57:03] 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 ...) {
UtilityClass::staticMethod();
}
vs
$instance = new UtilityClass();
for (... many times ...) {
$instance->staticMethod();
}
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
------------------------------------------------------------------------
[2012-10-26 16:09:57] 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.
------------------------------------------------------------------------
[2009-10-31 00:27:53] 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,
shouldn't).
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=47971
--
Edit this bug report at https://bugs.php.net/bug.php?id=47971&edit=1
Thread (7 messages)