Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123647
Content-Type: multipart/alternative;
 boundary="------------ewGk01wnpiDAkhTpXkD17nAa"
Message-ID: <a380fa4d-4014-4f20-9c96-ac8e6789c9e2@scriptfusion.com>
Date: Mon, 17 Jun 2024 13:54:44 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Static class
To: Mike Schinkel <mike@newclarity.net>
Cc: internals@lists.php.net
References: <0cf69a14-f1b5-4077-9d91-d7b579485eec@scriptfusion.com>
 <936e1aa3-48cc-4552-9f68-676ebcdeb596@rwec.co.uk>
 <04ae10a2-ceae-4996-a7fe-9b38d2f81ca2@scriptfusion.com>
 <82601236-3228-491E-B776-457331B41C6B@newclarity.net>
 <a5aad48e-5328-4c19-903b-3c3772dcdd7b@scriptfusion.com>
Content-Language: en-GB
In-Reply-To: <a5aad48e-5328-4c19-903b-3c3772dcdd7b@scriptfusion.com>
From: bilge@scriptfusion.com (Bilge)

This is a multi-part message in MIME format.
--------------ewGk01wnpiDAkhTpXkD17nAa
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 17/06/2024 13:49, Bilge wrote:
> On 16/06/2024 14:32, Mike Schinkel wrote:
>>
>>     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.
>>
> You wrote the perfect words. Even if I do not agree with all of your 
> six conclusions following, I agree with this preface 100%, to such an 
> extent that I think it should form the underpinning basis for all 
> further decisions on this RFC and be enshrined in the preamble of said 
> RFC, if indeed I ever acquire such permissions as are necessary to 
> actually write it.
>
> The idea of "implicit" versus "explicit" static classes is a clear and 
> powerful one that I think we can all understand, such that a 
> successful RFC would collapse this distinction; any failure to do so 
> would undermine the value of the feature entirely. As a concrete 
> example, then, prohibiting state in a static class is now completely 
> off the table simply because regular classes already support this 
> feature. Whilst some people have talked about idealogical aspirations 
> for this feature which sound valid in a vacuum, we must primarily 
> concern ourselves with the fact that this feature is being introduced 
> into an existing language, not a brand new language where such ideals 
> would have merit. And that is why this statement is so powerful: most 
> (but perhaps not all) of the answers to these disputed questions 
> follow naturally from the clear and guiding principle of this preface.
>
> Thank you so much, Mike, for this! I feel confident I can write this 
> RFC now, and with help from Lanre, we already have the beginnings of 
> an implementation, too!
>
> Cheers,
> Bilge
>
Furthermore, for absolute clarity and the avoidance of doubt, I believe 
this guiding principle can be enshrined on the following single sentence:

     "We cannot remove features from a static class that would otherwise 
be present in a standard class."

I believe following this principle we will arrive at the best 
implementation of static classes.

Cheers,
Bilge

--------------ewGk01wnpiDAkhTpXkD17nAa
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">On 17/06/2024 13:49, Bilge wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:a5aad48e-5328-4c19-903b-3c3772dcdd7b@scriptfusion.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div class="moz-cite-prefix">On 16/06/2024 14:32, Mike Schinkel
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:82601236-3228-491E-B776-457331B41C6B@newclarity.net">
        <blockquote
          style="margin: 0 0 0 40px; border: none; padding: 0px;"
          class="">
          <div>
            <div>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. </div>
            <div><br class="">
            </div>
            <div>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.  </div>
            <div><br class="">
            </div>
          </div>
        </blockquote>
      </blockquote>
      <p>You wrote the perfect words. Even if I do not agree with all of
        your six conclusions following, I agree with this preface 100%,
        to such an extent that I think it should form the underpinning
        basis for all further decisions on this RFC and be enshrined in
        the preamble of said RFC, if indeed I ever acquire such
        permissions as are necessary to actually write it.<br>
      </p>
      <p>The idea of "implicit" versus "explicit" static classes is a
        clear and powerful one that I think we can all understand, such
        that a successful RFC would collapse this distinction; any
        failure to do so would undermine the value of the feature
        entirely. As a concrete example, then, prohibiting state in a
        static class is now completely off the table simply because
        regular classes already support this feature. Whilst some people
        have talked about idealogical aspirations for this feature which
        sound valid in a vacuum, we must primarily concern ourselves
        with the fact that this feature is being introduced into an
        existing language, not a brand new language where such ideals
        would have merit. And that is why this statement is so powerful:
        most (but perhaps not all) of the answers to these disputed
        questions follow naturally from the clear and guiding principle
        of this preface.</p>
      <p>Thank you so much, Mike, for this! I feel confident I can write
        this RFC now, and with help from Lanre, we already have the
        beginnings of an implementation, too!</p>
      <p>Cheers,<br>
        Bilge<br>
      </p>
    </blockquote>
    <p>Furthermore, for absolute clarity and the avoidance of doubt, I
      believe this guiding principle can be enshrined on the following
      single sentence:</p>
    <p>    "We cannot remove features from a static class that would
      otherwise be present in a standard class."</p>
    <p>I believe following this principle we will arrive at the best
      implementation of static classes.</p>
    <p>Cheers,<br>
      Bilge<br>
    </p>
  </body>
</html>

--------------ewGk01wnpiDAkhTpXkD17nAa--