Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123809
Content-Type: multipart/alternative;
 boundary="------------fViKLKwCBmM8jI1dlOXodBsI"
Message-ID: <cf31ab47-780d-42f5-be33-2ea36cd6d86c@scriptfusion.com>
Date: Tue, 25 Jun 2024 09:03:20 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Static class
To: Stephen Reay <php-lists@koalephant.com>,
 Mike Schinkel <mike@newclarity.net>
Cc: Claude Pache <claude.pache@gmail.com>, ayesh@php.watch,
 php internals <internals@lists.php.net>
References: <eb3f59cc-3ed8-461a-a3a4-f6ba10ed31e1@scriptfusion.com>
 <88D83E92-94BE-4548-B398-8F5C74765FFD@gmail.com>
 <882BD9E0-42E9-4C84-A144-7C1DFC4CE5EB@newclarity.net>
 <DB280533-7FBE-41CD-B841-9BB163A75280@koalephant.com>
Content-Language: en-GB
In-Reply-To: <DB280533-7FBE-41CD-B841-9BB163A75280@koalephant.com>
From: bilge@scriptfusion.com (Bilge)

This is a multi-part message in MIME format.
--------------fViKLKwCBmM8jI1dlOXodBsI
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi guys,

On 25/06/2024 04:17, Stephen Reay wrote:
>>
>>     Given a primary purpose for being able to declare a class
>>     `static` is to *signal intent*, disallowing `abstract static`
>>     classes seems at odds with that goal.
>>
What is the /intent/ of `abstract static`? How is such intent different 
from just `static`?
> I agree that the `static` keyword is a much better fit here, however 
> there is one other aspect here that may come into it (as much as I 
> prefer the keyword approach): the Attribute approach is backwards 
> compatible (with a polyfill) to let code using this feature also run 
> on previous PHP releases. Given that this is mostly intended as a way 
> to signal intent about a pattern that's already in use, this may be 
> significant for library authors.
>
> Personally (as a library author) I don't think that ability is worth 
> the weirdness of an attribute vs a keyword, but it may be more 
> important for others who are voting, and I'd rather have the feature 
> with slightly odd syntax rather than not at all.
When I first saw the proposal to use an attribute instead of the 
keyword, I thought it absurd, but this idea has now been entertained by 
three people, and for the first time I have seen a compelling argument 
in favour of (early adoption). I must admit, I was too quick to judge 
this one. I had not considered that libraries will still not be able to 
use the `static` modifier with classes unless and until they drop 
support for PHP < 8.4, which may take a while! Of course, it is still of 
real benefit to first-party proprietary projects whom have upgraded. 
Nevertheless, the allure of early adoption is curious, and made me 
wonder whether we could do both, just to support early adoption in a 
backwards-compatible manner. However, this would be unprecedented and 
most likely not accepted; never before has the same feature been 
implemented two ways just to appease early adopters. I think the best 
compromise would be, for anyone so eager, to implement such support in 
community tools, e.g. PHPStan. That is, it should be perfectly possible 
to enforce the core semantics of the static class feature with a 
userland attribute and the necessary logic in static analysis tools, 
provided the library is well behaved and doesn't do anything too weird 
with variable variables, references, reflection or unserialize() to 
deliberately circumvent the restriction.

Cheers,
Bilge

--------------fViKLKwCBmM8jI1dlOXodBsI
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">Hi guys,</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">On 25/06/2024 04:17, Stephen Reay
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:DB280533-7FBE-41CD-B841-9BB163A75280@koalephant.com">
      <div>
        <blockquote type="cite">
          <div>
            <div
style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
              <blockquote
                style="margin: 0 0 0 40px; border: none; padding: 0px;">
                <div>
                  <div>Given a primary purpose for being able to declare
                    a class `static` is to <b>signal intent</b>,
                    disallowing `abstract static` classes seems at odds
                    with that goal.</div>
                </div>
              </blockquote>
            </div>
          </div>
        </blockquote>
      </div>
    </blockquote>
    What is the <i>intent</i> of `abstract static`? How is such intent
    different from just `static`?<br>
    <blockquote type="cite"
      cite="mid:DB280533-7FBE-41CD-B841-9BB163A75280@koalephant.com">
      <div>I agree that the `static` keyword is a much better fit here,
        however there is one other aspect here that may come into it (as
        much as I prefer the keyword approach): the Attribute approach
        is backwards compatible (with a polyfill) to let code using this
        feature also run on previous PHP releases. Given that this is
        mostly intended as a way to signal intent about a pattern that's
        already in use, this may be significant for library authors.</div>
      <div><br>
      </div>
      <div>Personally (as a library author) I don't think that ability
        is worth the weirdness of an attribute vs a keyword, but it may
        be more important for others who are voting, and I'd rather have
        the feature with slightly odd syntax rather than not at all.</div>
    </blockquote>
    When I first saw the proposal to use an attribute instead of the
    keyword, I thought it absurd, but this idea has now been entertained
    by three people, and for the first time I have seen a compelling
    argument in favour of (early adoption). I must admit, I was too
    quick to judge this one. I had not considered that libraries will
    still not be able to use the `static` modifier with classes unless
    and until they drop support for PHP &lt; 8.4, which may take a
    while! Of course, it is still of real benefit to first-party
    proprietary projects whom have upgraded. Nevertheless, the allure of
    early adoption is curious, and made me wonder whether we could do
    both, just to support early adoption in a backwards-compatible
    manner. However, this would be unprecedented and most likely not
    accepted; never before has the same feature been implemented two
    ways just to appease early adopters. I think the best compromise
    would be, for anyone so eager, to implement such support in
    community tools, e.g. PHPStan. That is, it should be perfectly
    possible to enforce the core semantics of the static class feature
    with a userland attribute and the necessary logic in static analysis
    tools, provided the library is well behaved and doesn't do anything
    too weird with variable variables, references, reflection or
    unserialize() to deliberately circumvent the restriction.<br>
    <p>Cheers,<br>
      Bilge<br>
    </p>
  </body>
</html>

--------------fViKLKwCBmM8jI1dlOXodBsI--