On Sun, Jun 16, 2024, at 11:17, Bilge 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:
>
>
> 1. Since a "static class" implies all members are static, should we still
> allow explicit static method declarations with the `static` keyword?
>
To keep it inline with readonly and abstract. I would look to those and follow
their rules.
>
> 2. Should `static` imply `final`?
> 2a. If yes, should `final` still be allowed to be explicitly declared,
> despite being implied?
>
I would allow it, though emit a warning that it’s unnecessary. That’s what I
would expect from a compiled language, anyway.
>
> 3. Should a "static class" prohibit inheritance?
>
I would think it should be allowed. This is one of the most annoying things
about static classes in C#. That being said, PHP has traits, so static classes
could theoretically use traits to provide inheritance-like behavior. Can traits
be marked static, or just classes?
>
> 4. Should a "static class" permit state?
>
Here’s the thing, there are still ways to get state even if you disallow it
(create a function called getState() that has an internal static array). Using
state in a static class is a code smell, for sure. However, constants should be
allowed and even those are quite limited in what values they can hold. Until
that gets cleared up, we should perhaps allow variables so complex constants
can exist (implementing the construction of them, however, should be left as an
exercise for the developer).
>
> 5. Should traits be permitted in a static class?
>
I hope so. Traits are some of the most abused super powers of PHP.
>
> 6. Which magic methods (if any) should be valid in a static class?
>
Are magic methods allowed in a static context? If so, only those should be
implementable.
> Based on my current understanding, I would propose the following answers to
> these questions:
>
>
> 1. In order to make upgrading simple and keep method intentions clear,
> `static` should not only be valid but also required on each method
> declaration, as usual for static methods.
> 2. Inheritance doesn't make much sense in a purely static context, despite
> the fact that PHP has a static resolution operator; I often find this is an
> anti-pattern. In any case, this is a non-BC issue if we lock down inheritance
> for now and later decide to open it up. Disabling inheritance also is in-line
> with the C# implementation of the same.
> 2a. Since under this proposal, `final` is implied, it should not be
> necessary (or allowed) to be specified. Upgrading would be simply a case of
> replacing `final` with `static` in-place.
> 3. As already mentioned, inheritance in a purely static context doesn't
> make much sense, and it's a non-BC break to prohibit it and later enable it.
> This decision is also in-line with the C# implementation.
> 4. Perhaps the most contentious decision, we could disable state and later
> enable it if there is a need, without BC. I personally cannot think of a time
> when I needed state in a static class. That said, I do not agree with
> disabling state within the language. In case someone is relying on static
> state in such a class, upgrading would be impossible; they would instead have
> to avoid marking the class as static, which defeats the purpose of this RFC.
> I believe we should support state, and if someone dislikes static state, they
> should enforce that with a code style rule in their project; this is not
> something that should be prohibited by the language itself as "regular"
> classes already allow this.
> 5. Provided a trait follows the rules of the static class (i.e. all members
> are static), it seems to me this should be allowed, though I have little use
> for it myself.
> 6. Given there are many magic methods, this topic probably deserves a
> separate discussion; it is not something I have spent a lot of time on thus
> far so it is just included for visibility at this time.
>
> If there are any strongly dissenting opinions on any of these points, or any
> significant points I may have missed, please share. Otherwise, I would be
> happy to draw up and RFC along these lines (notwithstanding I have no RFC
> karma at present), followed by an implementation once all outstanding
> questions are answered.
>
>
> Cheers,
> Bilge
>
>
> On 15/06/2024 14:53, Rowan Tommins [IMSoP] wrote:
>> On 15/06/2024 12:16, Bilge wrote:
>>>
>>> I want to introduce the `static` keyword at the class declaration level.
>>> That is, the following would be valid: `static class Foo {}`.
>>
>>
>> This has been proposed before, and was rejected at vote. It was nearly 10
>> years ago, so opinions may have changed, but it would be worth reading
>> through the prior discussion to anticipate or counter the objections raised,
>> and avoid re-treading the same ground.
>>
>> - RFC: https://wiki.php.net/rfc/abstract_final_class
>> - Pre-vote discussion threads: https://externals.io/message/79211 and
>> https://externals.io/message/79338
>> - Final vote thread: https://externals.io/message/79601
>>
>> Searching my list archive, I find that it came up again a few months ago,
>> which I'd entirely forgotten: https://externals.io/message/121717
>>
>> Slightly tangential, but some of the same discussion also came up on these
>> rather lengthy threads about "static class constructors":
>> https://externals.io/message/84602 and https://externals.io/message/85779
>>
>>
>> Regards,
>
>
— Rob
