Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123646
Content-Type: multipart/alternative;
 boundary="------------ZeA625N0NVerVJhTeceHWzdc"
Message-ID: <a5aad48e-5328-4c19-903b-3c3772dcdd7b@scriptfusion.com>
Date: Mon, 17 Jun 2024 13:49:26 +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>
Content-Language: en-GB
In-Reply-To: <82601236-3228-491E-B776-457331B41C6B@newclarity.net>
From: bilge@scriptfusion.com (Bilge)

This is a multi-part message in MIME format.
--------------ZeA625N0NVerVJhTeceHWzdc
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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

--------------ZeA625N0NVerVJhTeceHWzdc
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 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 type="cite"
      cite="mid:82601236-3228-491E-B776-457331B41C6B@newclarity.net"></blockquote>
  </body>
</html>

--------------ZeA625N0NVerVJhTeceHWzdc--