> On Jun 16, 2024, at 5:17 AM, Bilge <[email protected]> wrote:
>
> Let's start getting specific so we can make some progress.
>
> The goals of this RFC are fairly straightforward:
> Introduce the static keyword at the class level to preclude the need to create a
> private constructor. That is, __construct would be invalid in a static class.
> Prohibit instantiation of a static class with a language-level error.
> Prohibit declaration of instance members in a static class with a language-level error.
> However, as ever, there's a devil in the details. In particular, we need to consider the
> following:
>
To start, any limitations imposed on these new static classes that current classes can do that are
not intrinsically linked to their "staticness" would result in developers grudgingly
writing a class "statically" that is not declared as static. Imposing restrictions on
features that developers use in the wild would certainly cause them to consider the feature to be
dubiously excluded.
Not supporting all features used in the wild would result in developers not being able to use static
classes for new and/or refactored code if they believe they need those excluded features. This would
stop developers from signaling their intent to readers of their code and would stop developers from
being able to rely on reflection to discern static classes for new and/or refactored code when that
otherwise could have been possible.
Disabling existing features just for static classes would result in creating two forms of static
classes — explicit and implicit — and that IMO would be a miss for the addition of static
classes.
That said...
> 1. Since a "static class" implies all members are static, should we still allow
> explicit static method declarations with the static keyword?
>
Yes, but optional.
Supporting the static keyword for members would ease the transition for tooling, and
support those who prefer to be explicit in all the things.
OTOH, of all the things I mention below, this is my least firmly-held opinion.
> 2. Should static imply final?
>
No.
The primary PHP framework I wrote before I quite working professionally in PHP — although others
still use it — has a series of implied static classes, all of which inherit from a base implied
static class that provided services to all other implied static classes. To update this library to
a newer version of PHP with static classes would not be possible if static classes are assumed to be
final.
Further, Laravel — which I have never used but is simultaneously the most beloved framework in PHP
but also the most hated, depending on who you ask — has a base Model class that
Eloquent models inherit from, and a BaseController for custom controllers. Enforcing
final would leave Laravel out in the lurch for classes that are exactly the type of
classes that should be declared static.
If a developer wants their declared static class to be final they should be required to use the
final keyword, IMO.
BTW, see #4 and #5 why this is important.
> 3. Should a "static class" prohibit inheritance?
>
Isn't #3 just a rewording of #2?
> 4. Should a "static class" permit state?
>
Absolutely, without a doubt.
My PHP library uses static properties to keep track of certain data which I treated as immutable —
registering business information for use by static factory methods, and in some cases the factory
methods use arrays to store instances they create for processing and/or dispensing on demand late by
other static methods.
Laravel uses static properties in their service containers such as
Illuminate\Support\Facades\App, their Cache facade uses static properties, Eloquent
models maintain state in static properties, and developer written factory classes often use static
properties to track instances.
While we can ignore my library it would be much harder to ignore Laravel's use of state in
static properties.
> 5. Should traits be permitted in a static class?
>
Of course.
Laravel makes extensive use of traits in their implied static classes, in their core framework and
in Eloquent models, and they encourage Laravel application developers to use traits in their
applications.
Traits are a valuable code structuring mechanism as an alternate to inheritance more like
containment, and not supporting traits would, again, be leaving developers depending on it out in
the cold.
Also, final/inheritance might not be as critical to support if it were not for one capability that
PHP's traits are glaringly missing and that is their inability to allow developers to declare
properties and methods as private to the trait itself.
Of course if we add trait-private to traits then it would be less problematic to implied
final/not support inheritance, but I doubt we'd want to couple this potential RFC
with one that hasn't even been considered yet.
Even so, not supporting inheritance would mean not allowing implied static classes that use
inheritance to be refactored to use the static declaration.
> 6. Which magic methods (if any) should be valid in a static class?
>
Unless I am mistaken, the only magic method that support static function calls is
__callStatic() as everything else deals with instances, so I assume that it is the only
one that needs to be supported.
And yes, IMO it is critical to support __callStatic() since Laravel Facades (as well as
my own library) make use of it, and in Laravel's case, extensive use.
Of course there may(?) be newer PHP features on the horizon that are an alternate to
__callStatic() but supporting __callStatic() would make it easier for
developers to move to static classes as even automated tooling could make the conversion if
__callStatic() and all other features used in the wild are supported.
Anyway, that is my take. #fwiw
-Mike
P.S. To learn about Laravel's uses of implied static classes I asked ChatGPT[1], so if I got
anything wrong about Laravel I apologize as I was relying on ChatGPT not to hallucinate on this
topic. I assumed it was unlikely to hallucinate given there was so much info on the web there is
regarding Laravel for ChatGPT to train on.
[1] https://chatgpt.com/share/79eb330b-69ae-4104-b2ac-6e77955ec914