Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124607
Content-Type: multipart/alternative;
 boundary="------------kxWL71HFU14BAlW669vrekOD"
Message-ID: <4e7714cb-0d88-43f5-aa30-9adb799e0b28@seld.be>
Date: Fri, 26 Jul 2024 13:36:55 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2
To: Rob Landers <rob@bottled.codes>, internals@lists.php.net
References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com>
 <b5c0be62-ea39-47fb-a8f8-ab6cd5ee3dab@app.fastmail.com>
 <CP8P284MB2148CB72E1A6A7AB5F29E8F093AE2@CP8P284MB2148.BRAP284.PROD.OUTLOOK.COM>
 <a3154cde-73ca-4b8e-bf90-b9aeabd5fbce@app.fastmail.com>
 <66c4ac1c-b3d7-4b20-b986-1fe1a464f485@app.fastmail.com>
Content-Language: fr
In-Reply-To: <66c4ac1c-b3d7-4b20-b986-1fe1a464f485@app.fastmail.com>
From: j.boggiano@seld.be (Jordi Boggiano)

This is a multi-part message in MIME format.
--------------kxWL71HFU14BAlW669vrekOD
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 21.07.2024 11:21, Rob Landers wrote:
>
> On Sat, Jul 20, 2024, at 23:51, Larry Garfield wrote:
>> On Sat, Jul 20, 2024, at 7:22 AM, Rodrigo Vieira wrote:
>> > Will the alternative syntax on hook not even be put to a vote?
>>
>> It was, a year and a half ago when Aviz was first proposed.  The 
>> preference was split, but leaned toward the prefix-style syntax.  So 
>> we went with that.  I don't think we'll ever get everyone to want the 
>> same syntax, but we're using the one that was both somewhat more 
>> popular, and (as discussed in the RFC) arguably superior.
>>
>> As the "comments in yield from" thread has shown, *any* even slight 
>> change to PHP's syntax will require work from static analysis tools.  
>> That's the nature of the problem space, regardless of the syntax 
>> specifics.
>>
>> --Larry Garfield
>>
>
> Just to play devil’s advocate, it was also before we had property 
> hooks who advertised itself as a way to “wrap and guard access to 
> object properties” but we are simply ignoring their existence here.
>
Just to compare them, because my initial gut feel was to say "yes please 
just put this together with hooks"..

As far as I understand these would be the two options?

      class C {
          public protected(set) $answer { get => 42; set => { $this->answer = $value * 2; }
          public private(set) $publicReadOnly;
      }


      class C {
          public $answer { get => 42; protected set => { $this->answer = $value * 2; }
          public $publicReadOnly { private set; }
      }

And now that I see it spelled out more, I do agree that while it appears a bit more verbose, and this "(set)" looks odd at first, having all the visibility upfront is a lot clearer than having to read through the hooks to see what visibility applies.

Best,
Jordi

-- 
Jordi Boggiano
@seldaek -https://seld.be

--------------kxWL71HFU14BAlW669vrekOD
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 21.07.2024 11:21, Rob Landers wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:66c4ac1c-b3d7-4b20-b986-1fe1a464f485@app.fastmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <title></title>
      <style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style>
      <div><br>
      </div>
      <div>On Sat, Jul 20, 2024, at 23:51, Larry Garfield wrote:<br>
      </div>
      <blockquote type="cite" id="qt" style="">
        <div>On Sat, Jul 20, 2024, at 7:22 AM, Rodrigo Vieira wrote:<br>
        </div>
        <div>&gt; Will the alternative syntax on hook not even be put to
          a vote?<br>
        </div>
        <div><br>
        </div>
        <div>It was, a year and a half ago when Aviz was first
          proposed.  The preference was split, but leaned toward the
          prefix-style syntax.  So we went with that.  I don't think
          we'll ever get everyone to want the same syntax, but we're
          using the one that was both somewhat more popular, and (as
          discussed in the RFC) arguably superior.<br>
        </div>
        <div><br>
        </div>
        <div>As the "comments in yield from" thread has shown, *any*
          even slight change to PHP's syntax will require work from
          static analysis tools.  That's the nature of the problem
          space, regardless of the syntax specifics.<br>
        </div>
        <div><br>
        </div>
        <div>--Larry Garfield<br>
        </div>
        <div><br>
        </div>
      </blockquote>
      <div><br>
      </div>
      <div>Just to play devil’s advocate, it was also before we had
        property hooks who advertised itself as a way to “wrap and guard
        access to object properties” but we are simply ignoring their
        existence here.<br>
      </div>
      <div><br>
      </div>
    </blockquote>
    <p>Just to compare them, because my initial gut feel was to say "yes
      please just put this together with hooks"..<br>
    </p>
    <p>As far as I understand these would be the two options?<br>
    </p>
    <pre class="moz-quote-pre" wrap="">     class C {
         public protected(set) $answer { get =&gt; 42; set =&gt; { $this-&gt;answer = $value * 2; }
         public private(set) $publicReadOnly;
     }


     class C {
         public $answer { get =&gt; 42; protected set =&gt; { $this-&gt;answer = $value * 2; }
         public $publicReadOnly { private set; }
     }

And now that I see it spelled out more, I do agree that while it appears a bit more verbose, and this "(set)" looks odd at first, having all the visibility upfront is a lot clearer than having to read through the hooks to see what visibility applies.

Best,
Jordi
</pre>
    <p></p>
    <pre class="moz-signature" cols="72">-- 
Jordi Boggiano
@seldaek - <a class="moz-txt-link-freetext" href="https://seld.be">https://seld.be</a></pre>
  </body>
</html>

--------------kxWL71HFU14BAlW669vrekOD--