Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123576 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 19CC31A009C for ; Tue, 11 Jun 2024 06:47:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1718088535; bh=tQ+rxbqNVTFG8N+UePpDyDTXWiqiaiWVjmLg8fLl38w=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=hjw/AXJfB9yTuZp8jSFyOk8mj4Qc0nsGPeNKK0u90hzekBCBhDxOLeks7xwR9MsEG o66EeQJdGx5e1Cs43Tm6W1jTEAmUOKm8AlCNiuQQ3Qa5cbcijNkQMMdk+ulE3vxIAS onEuQFJcr+ynakUoAkdofHAn1qI46xuZMdiCPcCGqibQIZy8Iz4JT4daKHxORg8NJr 1N0NqxTQILEyZuJa+ycKKHAUf0S2QmKxeGiSNkOAuENIyU31rJbUgoQ+gsiBA4n+Wl KNrGFjeqQzls1H7KNrDciL2+mARN7iZJRvbw84jJCthEsaLTT4vyX8p5v8HmqTt59S wEWHBO1HweKyA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id EB7C618006F for ; Tue, 11 Jun 2024 06:48:53 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from fout5-smtp.messagingengine.com (fout5-smtp.messagingengine.com [103.168.172.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 11 Jun 2024 06:48:53 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfout.nyi.internal (Postfix) with ESMTP id 2B54E1380120; Tue, 11 Jun 2024 02:47:45 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Tue, 11 Jun 2024 02:47:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm2; t=1718088465; x= 1718174865; bh=xLyFN0EsI+bUZy15aqqVPi/skpnRDNh9G3+HLYbk2aU=; b=w NUayVwiTsXkAMm+fEIWLyk0fgJUYhKwp9OFfMI93qDiBypbOQQXDOhK+5ZREnMBI fJp9ok7MPbRjd1gdwvp7sP4WIxxJddSYuft9JWoA5n4tKXynf4PZwYjF5RBNS5FZ 6wqHxY43B0hZP2yu7qMDjrXnp4TEe86DMjYsYws0PM1/BMlgEkdloXdUA2eIdTU0 MG7xADkfCkWo02UL/ctLr+08+zHCjTlBMK0PzPkb9pyFz1kpBEatGMNulngg2zW1 wevRXH4vhNmd6y8yYq/yQ/aA/CB5H5SK5KLEI+0TXFY7cdSLeCTAwxndcUYxCfLy L2l6me9fxSvaXflxWXR5w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1718088465; x=1718174865; bh=xLyFN0EsI+bUZy15aqqVPi/skpnR DNh9G3+HLYbk2aU=; b=QaXfMALehYDlPRzYhLgi1KD7JbD9l4T0P6N6egsz1blA p84OrGzB+ROU108uvW3MGaYdfTUVEbgVKUUtlqMBfYK5fRVTihoobV6n13zIm8Sq q1uU0HmyCjENJsRZPXQgI9KJqgjvgyUbL69u3UP+2aBMwHFCVk/1FasSe7QxHle1 AMwNlGoHWKd8DvzYmBQzsIrSQE6X22fB2732kb5/pR6Kk3xPt+pwwc6rca3oTRZR nzCbmmtD0tFjk5/DxD7eN4emBLO7FfmD5n+8dYhV1OkaLSDfByoxE0hEOBhrzKnB WpdQyMjeFqvkbE5TrHPkVczEf2OoBdkCh8+besIyKw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfeduuddguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgesrgdtreerreerjeenucfhrhhomhepfdft ohgsucfnrghnuggvrhhsfdcuoehrohgssegsohhtthhlvggurdgtohguvghsqeenucggtf frrghtthgvrhhnpefgvdefjeefvddvteeigeekhfevjeeiffeuudettdethfdtieefgeet hfdvveevgfenucffohhmrghinhepphhhphdrnhgvthenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrohgssegsohhtthhlvggurdgtohguvghs X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id BC09015A0093; Tue, 11 Jun 2024 02:47:44 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-515-g87b2bad5a-fm-20240604.001-g87b2bad5 Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 Message-ID: <43606ecd-8838-476d-8fdf-acc6dbe26359@app.fastmail.com> In-Reply-To: References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com> Date: Tue, 11 Jun 2024 08:47:24 +0200 To: "Rodrigo Vieira" , "Larry Garfield" , Tiffany Cc: "php internals" Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2 Content-Type: multipart/alternative; boundary=e88bacc3e5134d62a598bf31cbfecd77 From: rob@bottled.codes ("Rob Landers") --e88bacc3e5134d62a598bf31cbfecd77 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 10, 2024, at 19:51, Rodrigo Vieira wrote: > I didn't like the `Prefix-style` syntax. I prefer the `Hook-embedded-s= tyle` syntax. First let's look at the counterpoints of the `Prefix-style= ` syntax: >=20 > ## 1) "`Prefix-style` is more visually scannable" > > The set visibility is 10 lines away from the get visibility! >=20 > Solution: > ```php > class HookEmbeddedStyle > { > public string $phone { > private set { > $this->phone =3D implode('', array_filter(fn($c) =3D> is_n= umeric($c), explode($value))) > } > get { > if (!$this->phone) { > return ''; > } > if ($this->phone[0] =3D=3D=3D 1) { > return 'US ' . $this->phone; > } > return 'Intl +' . $this->phone; > } > } > } > ``` > The set visibility is not 10 lines away from the get visibility if you= put it at the top. For me this is about code convention, not about synt= actic structure: > only put the hook with explicit visibility at the top, when some of th= e hooks do not have explicit visibility! >=20 > ## 2) "`Prefix-style` is shorter" > ```php > public private(set) string $name; >=20 > public string $name { private set; } > ``` >=20 > Irrelevant to consider 1-2 characters. > If you break the lines needed for the hook block, the line (the horizo= ntal size) is smaller when using `Hook-embedded-style` and in my opinion= it is more readable because there is less information per line: > ```php > public private(set) string $name; >=20 > public string $name { > private set; > } > ``` >=20 > ## 3) "`Prefix-style` doesn't presume a connection with hooks" > > As noted above in "Interaction with hooks", visibility controls exis= t independently of hooks. >=20 > I agree, but with Property Hooks, this should now define the overall v= isibility only. Like a bigger gate that you open, and there are other do= ors defining the visibility of the operations get, set (hooks). >=20 > > In fact, as implemented, they don't interact at all. Using hook synt= ax for visibility controls is therefore surprising and confusing. >=20 > Why "surprising and confusing"? I see hooks as a different kind of fun= ction/method.=20 > Property Hooks RFC shouldn't pass without requiring hook parentheses, = for any hook when the property is not abstract. The `$value` in the `set= ` hook seems to come out of nowhere to some people (the exception is for= hooks declared on an abstract property which you can define without par= ameters and thus you are free to define whatever parameters you want on = the concrete property). >=20 > When you define a method in PHP, it should be possible to omit the "fu= nction", but the parameters should be required because that's the nature= of a function/method: to have parameters. >=20 > ## 4) "It's non-obvious in `Hook-embedded-style` what hook behavior sh= ould be implied" >=20 > > ...So =E2=80=9Carrays with hooks can do less=E2=80=9D is already an = established fact of the language. However, if the hook-style syntax is u= sed for visibility: >=20 > ```php > class A > { > public array $arr { protected set; } > } > =20 > class B extends A > { > public function add(int $val) > { > // Should this be legal? > $this->arr[] =3D $val; > } > } > =20 > $b =3D new B(); > =20 > $b->add(5); > ``` > First of all: non-abstract property hook must have a body. > Second: when asymmetric visibility is explicit, it means that symmetri= c visibility is implicit: a declared hook that does not have declared vi= sibility has the same general visibility as the property, in this case: = public. >=20 > Third: > There's another limitation on hooks here that makes things a bit confu= sing: there's a missing hook for a specific operation because you can cl= early separate the `set` from the `push` operation... >=20 > Solution: > ```php > abstract class A > { > abstract public array $arr { > push; // Hook available only for "array" type properties only;= public visibility > private set; > } > } >=20 > class B extends A > { > public array $arr { > push ($value) { // `public push ...` here is redundant > // Mandatory to implement logic here. > } > private set ($value) { > // Mandatory to Implement logic here. > } > } >=20 > public function __construct () > { > // Legal =E2=9C=85 (set hook is protected) > $this->arr =3D [1]; // call set hook > } > public function add(int $value) > { > // Legal =E2=9C=85 (push hook is public) > $this->arr[] =3D $value; // call push hook > } > } >=20 > $b =3D new B(); >=20 > $b->add(5); > $b->arr; // Legal =E2=9C=85 (Inherited from the general visibility tha= t is public)=20 > $b->arr =3D [1, 2, 3]; // Fatal error =E2=9D=8C - access to set hook i= s private only > $b->arr[] =3D 4; // Legal =E2=9C=85 - call public push hook > ``` >=20 > My point: `Prefix-style` is not future-proof > ## 1) The `Prefix-style` is not compatible with new hooks > If more hooks are added in the future, such as the `push` hook for arr= ays or even a hook that is compatible with all types such as `init`, `Ho= ok-embedded-style` will become compatible, but `Prefix-style` not. >=20 > ## 2) Hook overloading > If hook overloading is added in the future, `Prefix-style` would not b= e supported to have this granular visibility into operations. For exampl= e, it might be possible to add a public hook and a protected hook for th= e same operation, where one would be triggered if the operation occurred= from outside the class, and the other if the operation occurred from in= side the class. > Em 10 de jun. de 2024 13:15 -0300, Tiffany escreveu: >>=20 >> On Wed, May 29, 2024, 2:16=E2=80=AFPM Larry Garfield wrote: >>> As promised, Ilija and I offer this revised version of asymmetric vi= sibility.=20 >>>=20 >>> https://wiki.php.net/rfc/asymmetric-visibility-v2 >>>=20 >>> It's still essentially the same as last year's version, but with a f= ew adjustments and changes: >>>=20 >>> * readonly properties are now supported in a logical fashion. >>> * We've brought back the abbreviated form, as public-read, something= else set is the most common use case. >>> * The section on magic methods has been greatly simplified. The imp= lementation itself hasn't changed, but the explanation is a lot less con= fusing now. >>> * We've explained how aviz interacts with hooks (they don't, really)= and with interface properties (in the obvious way), which didn't exist = at the time of the last draft. >>> * We've added a section with examples of how aviz is a concrete impr= ovement, even in a world with readonly and hooks. >>> * We've added a section discussing why the prefix-style syntax was c= hosen. >>>=20 >>> *dons flame retardant suit* >>>=20 >>> -- >>> Larry Garfield >>> larry@garfieldtech.com >>=20 >> Sending an email to quickly enable a new mailing list subscriber to e= ngage in the conversation. I=E2=80=99m also not a fan of the prefix style, but for different reason= s. My main reason is that it increases the minimum line-length, potentia= lly forcing you to chop things down into awkward looking lines: public private(set) string $longvarname { get; set; } I find that extremely hard to scan, but maybe others do not. The more na= tural looking syntax is easier to scan and reason about (IMHO): public string $longvarname { get; private set; } If I=E2=80=99m having to read the code, I prefer to have everything near= where it is used so I don=E2=80=99t have to scroll up to the top and se= e its visibility. Granted, I haven=E2=80=99t used property hooks and I h= ave no idea how IDEs will help here; maybe it is a non-issue =E2=80=94 b= ut I guess people still have to do code reviews which very rarely comes = with IDE powers. =E2=80=94 Rob --e88bacc3e5134d62a598bf31cbfecd77 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 10,= 2024, at 19:51, Rodrigo Vieira wrote:
I didn't like the `Prefix-style` syntax. I prefer the `Hook-embed= ded-style` syntax. First let's look at the counterpoints of the `Prefix-= style` syntax:

## 1) "`Prefix-style` is m= ore visually scannable"
> The set visibility is 10 lin= es away from the get visibility!

Solution= :
```php
class HookEmbeddedStyle
=
{
    public string $phone {
        private set {
&n= bsp;           $this->phone =3D implode= ('', array_filter(fn($c) =3D> is_numeric($c), explode($value)))
        }
  =      get {
       &nb= sp;    if (!$this->phone) {
   &nb= sp;            return '';
&= nbsp;           }
 &nb= sp;          if ($this->phone[0] =3D=3D=3D 1= ) {
              = ;  return 'US ' . $this->phone;
   &nbs= p;        }
      = ;      return 'Intl +' . $this->phone;
=         }
    }
}
```
The set visibility is = not 10 lines away from the get visibility if you put it at the top. For = me this is about code convention, not about syntactic structure:
only put the hook with explicit visibility at the top, when some= of the hooks do not have explicit visibility!

=
## 2) "`Prefix-style` is shorter"
```php
<= div> public private(set) string $name;

pu= blic string $name { private set; }
```
Irrelevant to consider 1-2 characters.
If yo= u break the lines needed for the hook block, the line (the horizontal si= ze) is smaller when using `Hook-embedded-style` and in my opinion it is = more readable because there is less information per line:
= ```php
public private(set) string $name;
=
public string $name {
   privat= e set;
}
```

## 3) "`Prefix-style` doesn't presume a connection with hooks"
> As noted above in "Interaction with hooks", visibility cont= rols exist independently of hooks.

I agre= e, but with Property Hooks, this should now define the overall visibilit= y only. Like a bigger gate that you open, and there are other doors defi= ning the visibility of the operations get, set (hooks).
<= br>
> In fact, as implemented, they don't interact at all.= Using hook syntax for visibility controls is therefore surprising and c= onfusing.

Why "surprising and confusing"?= I see hooks as a different kind of function/method. 
Property Hooks RFC shouldn't pass without requiring hook parentheses, = for any hook when the property is not abstract. The `$value` in the `set= ` hook seems to come out of nowhere to some people (the exception is for= hooks declared on an abstract property which you can define without par= ameters and thus you are free to define whatever parameters you want on = the concrete property).

When you define a= method in PHP, it should be possible to omit the "function", but the pa= rameters should be required because that's the nature of a function/meth= od: to have parameters.

## 4) "It's non-o= bvious in `Hook-embedded-style` what hook behavior should be implied"

> ...So =E2=80=9Carrays with hooks can d= o less=E2=80=9D is already an established fact of the language. However,= if the hook-style syntax is used for visibility:

```php
class A
{
&= nbsp;   public array $arr { protected set; }
}<= br>
 
class B extends A
{<= br>
    public function add(int $val)
    {
       &n= bsp;// Should this be legal?
       &= nbsp;$this->arr[] =3D $val;
    }
}
 
$b =3D new B();
 
$b->add(5);
```
First of all: non-abstract property hook must have a body.
Second: when asymmetric visibility is explicit, it means that s= ymmetric visibility is implicit: a declared hook that does not have decl= ared visibility has the same general visibility as the property, in this= case: public.

Third:
Ther= e's another limitation on hooks here that makes things a bit confusing: = there's a missing hook for a specific operation because you can clearly = separate the `set` from the `push` operation...

Solution:
```php
abstract class A
{
    abstract public array = $arr {
        push; // Hook ava= ilable only for "array" type properties only; public visibility
        private set;
&nbs= p;   }
}

class B= extends A
{
    public arr= ay $arr {
        push ($value) = { // `public push ...` here is redundant
   &nb= sp;        // Mandatory to implement logic here.
=
        }
 &nbs= p;      private set ($value) {
  = ;          // Mandatory to Implement logic here= .
        }
 = ;   }

    public= function __construct ()
    {
        // Legal =E2=9C=85 (set hook is pro= tected)
        $this->arr =3D= [1]; // call set hook
    }
    public function add(int $value)
&nbs= p;   {
        // Lega= l =E2=9C=85 (push hook is public)
     &nb= sp;  $this->arr[] =3D $value; // call push hook
&= nbsp;   }
}

$b =3D= new B();

$b->add(5);
$= b->arr; // Legal =E2=9C=85 (Inherited from the general visibility tha= t is public) 
$b->arr =3D [1, 2, 3]; // Fatal err= or =E2=9D=8C - access to set hook is private only
$b->= arr[] =3D 4; // Legal =E2=9C=85 - call public push hook
`= ``

My point: `Prefix-style` is not future= -proof
## 1) The `Prefix-style` is not compatible with ne= w hooks
If more hooks are added in the future, such as th= e `push` hook for arrays or even a hook that is compatible with all type= s such as `init`, `Hook-embedded-style` will become compatible, but `Pre= fix-style` not.

## 2) Hook overloading
If hook overloading is added in the future, `Prefix-style` = would not be supported to have this granular visibility into operations.= For example, it might be possible to add a public hook and a protected = hook for the same operation, where one would be triggered if the operati= on occurred from outside the class, and the other if the operation occur= red from inside the class.
Em 10 de jun. de 2024 13:15 -0300, Tiffany <tiffany.k.= taylor@gmail.com> escreveu:

On Wed, May 29, 2024, 2:16=E2=80=AFPM Larr= y Garfield <larry@garfieldt= ech.com> wrote:
As promised, Ilija and I offer this= revised version of asymmetric visibility. 


It's still es= sentially the same as last year's version, but with a few adjustments an= d changes:

* readonly properties are now = supported in a logical fashion.
* We've brought back the = abbreviated form, as public-read, something else set is the most common = use case.
* The section on magic methods has been greatly= simplified.  The implementation itself hasn't changed, but the exp= lanation is a lot less confusing now.
* We've explained h= ow aviz interacts with hooks (they don't, really) and with interface pro= perties (in the obvious way), which didn't exist at the time of the last= draft.
* We've added a section with examples of how aviz= is a concrete improvement, even in a world with readonly and hooks.
=
* We've added a section discussing why the prefix-style synt= ax was chosen.

*dons flame retardant suit= *

--
  Larry Garfield=

Sending a= n email to quickly enable a new mailing list subscriber to engage in the= conversation.

<= /div>
I=E2=80=99m also not a fan of the prefix style, but for differ= ent reasons. My main reason is that it increases the minimum line-length= , potentially forcing you to chop things down into awkward looking lines= :

public
private(set)
string $longvarname {
 get;
&nbs= p;set;
}

I find that extremel= y hard to scan, but maybe others do not. The more natural looking syntax= is easier to scan and reason about (IMHO):

public
string $longvarname {
 get;
=
 private set;
}

If I=E2=80=99m having to read the code, I prefer to have everything n= ear where it is used so I don=E2=80=99t have to scroll up to the top and= see its visibility. Granted, I haven=E2=80=99t used property hooks and = I have no idea how IDEs will help here; maybe it is a non-issue =E2=80=94= but I guess people still have to do code reviews which very rarely come= s with IDE powers.

=E2=80= =94 Rob
--e88bacc3e5134d62a598bf31cbfecd77--