Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123779
Precedence: bulk
MIME-Version: 1.0
References: <eb3f59cc-3ed8-461a-a3a4-f6ba10ed31e1@scriptfusion.com> <88D83E92-94BE-4548-B398-8F5C74765FFD@gmail.com>
In-Reply-To: <88D83E92-94BE-4548-B398-8F5C74765FFD@gmail.com>
Date: Mon, 24 Jun 2024 11:07:58 +0200
Message-ID: <CAB-BujbnNfNZpEwSayJNc0n5ZvjZCP6+kZ9y=G1nJ9yUU7qiAA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Static class
To: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: andreas@dqxtech.net (Andreas Hennings)

> 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 `#[Ove=
rride]` 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 declaration=
s still require the static keyword in a static class. Marking a class reado=
nly makes marking properties with the same optional, thus one might argue s=
tatic 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 t=
hroughout 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, wit=
hout 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 pre=
sent 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.