Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123625
Content-Type: multipart/alternative;
 boundary="------------pjJq5oPjwJ7RvGzqwEh1wEBh"
Message-ID: <04ae10a2-ceae-4996-a7fe-9b38d2f81ca2@scriptfusion.com>
Date: Sun, 16 Jun 2024 10:17:37 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Static class
To: internals@lists.php.net
References: <0cf69a14-f1b5-4077-9d91-d7b579485eec@scriptfusion.com>
 <936e1aa3-48cc-4552-9f68-676ebcdeb596@rwec.co.uk>
Content-Language: en-GB
In-Reply-To: <936e1aa3-48cc-4552-9f68-676ebcdeb596@rwec.co.uk>
From: bilge@scriptfusion.com (Bilge)

This is a multi-part message in MIME format.
--------------pjJq5oPjwJ7RvGzqwEh1wEBh
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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?
   2. Should `static` imply `final`?
     2a. If yes, should `final` still be allowed to be explicitly 
declared, despite being implied?
   3. Should a "static class" prohibit inheritance?
   4. Should a "static class" permit state?
   5. Should traits be permitted in a static class?
   6. Which magic methods (if any) should be valid in a static class?

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,
>

--------------pjJq5oPjwJ7RvGzqwEh1wEBh
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Let's start getting specific so we can
      make some progress.</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">The goals of this RFC are fairly
      straightforward:</div>
    <div class="moz-cite-prefix">
      <ul>
        <li>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.</li>
        <li>Prohibit instantiation of a static class with a
          language-level error.</li>
        <li>Prohibit declaration of instance members in a static class
          with a language-level error.<br>
        </li>
      </ul>
      <p>However, as ever, there's a devil in the details. In
        particular, we need to consider the following:<br>
      </p>
      <p>  1. Since a "static class" implies all members are static,
        should we still allow explicit static method declarations with
        the `static` keyword?<br>
          2. Should `static` imply `final`?<br>
            2a. If yes, should `final` still be allowed to be explicitly
        declared, despite being implied?<br>
          3. Should a "static class" prohibit inheritance?<br>
          4. Should a "static class" permit state?<br>
          5. Should traits be permitted in a static class?<br>
          6. Which magic methods (if any) should be valid in a static
        class?<br>
      </p>
      <p>Based on my current understanding, I would propose the
        following answers to these questions:</p>
      <p>  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.<br>
          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.<br>
            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.<br>
          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.<br>
          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.<br>
          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.<br>
          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.</p>
      <p>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.</p>
      <p>Cheers,<br>
        Bilge<br>
      </p>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">On 15/06/2024 14:53, Rowan Tommins
      [IMSoP] wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:936e1aa3-48cc-4552-9f68-676ebcdeb596@rwec.co.uk">On
      15/06/2024 12:16, Bilge wrote:
      <br>
      <blockquote type="cite">
        <br>
        I want to introduce the `static` keyword at the class
        declaration level. That is, the following would be valid:
        `static class Foo {}`. </blockquote>
      <br>
      <br>
      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.
      <br>
      <br>
      - RFC: <a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/abstract_final_class">https://wiki.php.net/rfc/abstract_final_class</a>
      <br>
      - Pre-vote discussion threads: <a class="moz-txt-link-freetext" href="https://externals.io/message/79211">https://externals.io/message/79211</a>
      and <a class="moz-txt-link-freetext" href="https://externals.io/message/79338">https://externals.io/message/79338</a>
      <br>
      - Final vote thread: <a class="moz-txt-link-freetext" href="https://externals.io/message/79601">https://externals.io/message/79601</a>
      <br>
      <br>
      Searching my list archive, I find that it came up again a few
      months ago, which I'd entirely forgotten:
      <a class="moz-txt-link-freetext" href="https://externals.io/message/121717">https://externals.io/message/121717</a>
      <br>
      <br>
      Slightly tangential, but some of the same discussion also came up
      on these rather lengthy threads about "static class constructors":
      <a class="moz-txt-link-freetext" href="https://externals.io/message/84602">https://externals.io/message/84602</a> and
      <a class="moz-txt-link-freetext" href="https://externals.io/message/85779">https://externals.io/message/85779</a>
      <br>
      <br>
      <br>
      Regards,
      <br>
      <br>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>

--------------pjJq5oPjwJ7RvGzqwEh1wEBh--