> I am pleased to present my first RFC: Static class
To recap my opinion from the other thread:
I generally support the idea to have a label to slap on all-static
classes, to make that contract more explicit.
The goal is not to promote a specific use of the language, but to add
clarity to what already exists.
Since my last response on the other thread, I warmed up more to
namespaced floating functions, thanks Larry :)
At the same time I don't see static methods and all-static classes
fully going away soon, so I still support them having a label.
But...
> Why is it a class-level flag and not an attribute (similar to the #[Override]
> attribute in PHP 8.3) ?
I don't know that it needs to be a language keyword.
An attribute would be ok for me, or even just a doc tag with phpstan.
In fact maybe a feature request with phpstan could be a starting point.
> One question our razor cannot answer is whether static member declarations still require the
> static keyword in a static class. Marking a class readonly makes marking properties with the same
> optional, thus one might argue static should follow suit. However, I opine it should not. Unlike
> readonly, which typically applies to properties declared near the head of the class (by convention)
> where the same mark is also applied, static members appear throughout the full length of the class
> body. That is, it should be apparent when jumping anywhere into a static class that its members are
> static, without having to check the class declaration.
I prefer that the static keyword be required on the members.
This supports the common use case of incremental refactoring, where
methods are moved from one class to another, or a git merge where one
branch adds the class-level static keyword, while another commit adds
another method.
> We cannot remove features from a static class that would otherwise be present in a standard
> class.
I think I get the intent of this statement, but I don't really vibe
with the wording.
I would say we should limit the scope of a modifier keyword to its essence.
And we should not remove features that are already being used in
classes that would naturally qualify for the class-level static
modifier.