Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:122763 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 230A81A009C for ; Tue, 26 Mar 2024 20:18:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1711484362; bh=fYoWOPJkltzKPPGsZ4EtvCDt+KgIJ1rkjFG16ce1Yvk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=IrYrmQPOKAwA6EmQaiF1+xR53KYxJRk6l9FADHRlflMLaGEEUoecPfM0NaVekE+50 POstiXAsd8v6/Sr6M8aS99lvNfFzOv15jdR5Ods+/hDKyKkoEgPxS70zYDjJK4T8T4 Tuo5Q5r4zjwcNXv2W6S7VG5gTiFMIDZQ6OXT8uLal7LMLTjh0wMwGLj2rm3mgXmKHK LZfUKfIIUcc80Rv1OWWGJOaQTTBCJZuMDZZ+oiZR2DsNb2dQRk1PrFL0atvspWlDCg StGpHni4ag/OzeQWpkwQUUBtrGSkVtrJ9BRxH+rafUC5oxynfiy58h2bnqPX/85H7p Vs4n0LJi+9zTw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8A2E8180072 for ; Tue, 26 Mar 2024 20:19:20 +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_PASS,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from smtp-out3.simply.com (smtp-out3.simply.com [94.231.106.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 26 Mar 2024 20:19:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.simply.com (Simply.com) with ESMTP id 4V41NF1GHRz681L for ; Tue, 26 Mar 2024 21:18:53 +0100 (CET) Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by smtp.simply.com (Simply.com) with ESMTPSA id 4V41ND6Qy8z67t3 for ; Tue, 26 Mar 2024 21:18:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=givoni.dk; s=unoeuro; t=1711484333; bh=Zd1+Dx7GQpjA7vM+9j714jPAk1t59Au3GX4H0m4IC8Y=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=PikyKt+j24fpRfX0w3IIX+9KxdCPjygOEMKB4NobuB6gq+DNe8TX26RwlUzNljN1O mfEzy1Gc4DfkvfO6RHNTwsUAMTll9tYYI7Kax3tW6ogxdTvMQvaBKacd4Ye096Rzxd dB0/utzP1BjDdVHKMVpozSHrtrIyoaobGLjMBYtE= Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-609ed7ca444so58742117b3.1 for ; Tue, 26 Mar 2024 13:18:52 -0700 (PDT) X-Gm-Message-State: AOJu0YyZOld1lSi752+bEdTaE0krSyYTxbASGH3Z3mYfU0/DzLQs0Fzw 5oM2oFP0JfHvg4nj9oYasiIAISZTp9eTDjpUvjSd4t+WZt/nZi5V8PzssKAgu7pl+T9MilgRA5j I+GVEl0HlXOgZcFxft9se8+/l18M= X-Google-Smtp-Source: AGHT+IE57SuEI7+Yy7AsjnzW1RbqSSoUh7nA77hbLT+rTFGTY5NQo7xBplCu7M62E6BCQtGbJpZqpU2VQfjquQLxoz4= X-Received: by 2002:a0d:c685:0:b0:60a:4d2:3f6d with SMTP id i127-20020a0dc685000000b0060a04d23f6dmr1865223ywd.47.1711484331456; Tue, 26 Mar 2024 13:18:51 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 26 Mar 2024 21:18:40 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2 To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="0000000000009d89d2061495ff31" From: jakob@givoni.dk (Jakob Givoni) --0000000000009d89d2061495ff31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 21, 2024, 19:57 Larry Garfield wrote: > Hello again, fine Internalians. > > After much on-again/off-again work, Ilija and I are back with a more > polished property access hooks/interface properties RFC. It=E2=80=99s 99= % > unchanged from last summer; the PR is now essentially complete and more > robust, and we were able to squish the last remaining edge cases. > > Baring any major changes, we plan to bring this to a vote in mid-March. > > It=E2=80=99s long, but that=E2=80=99s because we=E2=80=99re handling ever= y edge case we could > think of. Properties involve dealing with both references and inheritanc= e, > both of which have complex implications. We believe we=E2=80=99ve identi= fied the > most logical handling for all cases, though. > > Note the FAQ question at the end, which explains some design choices. > > There=E2=80=99s one outstanding question, which is slightly painful to as= k: > Originally, this RFC was called =E2=80=9Cproperty accessors,=E2=80=9D whi= ch is the > terminology used by most languages. During early development, when we ha= d > 4 accessors like Swift, we changed the name to =E2=80=9Chooks=E2=80=9D to= better indicate > that one was =E2=80=9Chooking into=E2=80=9D the property lifecycle. Howe= ver, later > refinement brought it back down to 2 operations, get and set. That makes > the =E2=80=9Chooks=E2=80=9D name less applicable, and inconsistent with w= hat other > languages call it. > > However, changing it back at this point would be a non-small amount of > grunt work. There would be no functional changes from doing so, but it=E2= =80=99s > lots of renaming things both in the PR and the RFC. We are willing to do = so > if the consensus is that it would be beneficial, but want to ask before > putting in the effort. > > -- > Larry Garfield > larry@garfieldtech.com Hi, thanks for the RFC and the effort put into trying to make it palatable to skeptical minds! After reading most of the discussion in this thread I believe that the RFC in its current form can work and that I will get used to it's "peculiarities", but an idea occurred to me that may have some advantages, so here goes: Use the "set" keyword that you've already introduced to set the raw value of a "backed" property: public int $name { set { set strtoupper($value); } } Or when used in short form: public int $name { set =3D> set strtoupper($value); } Advantages in no particular order: 1. Shorter than $this->name 2. No magic $field 3. Short and long form works the same Disadvantage: "Set" can only be used to set the raw value inside the hook method itself. Or maybe that's a good thing too. To be honest, I don't love that $this->name sometimes goes through the hook and sometimes not. I'd prefer if the raw value could only be accessed inside the hooks or via a special syntax like f.ex. $this->name:raw If there are any use cases or technical details that I've missed that would make this syntax unfavourable, I apologize. Another observation (I apologize for being late to the game but it was a long RFC and thread to read through): What would happen if we stopped talking about virtual vs. backed properties? Couldn't we just treat a property that was never set the same as any other uninitialized property? What I mean is, that if you try to access the raw value of a property with a set hook that never sets its own raw value, you'd get either null or Type= d property [...] must not be accessed before initialization, just like you'd expect if you're already used to modern php. Of course you'd just write your code correctly so that that never happens. It's already the case that uninitialized properties are omitted when serializing the object so there would be no difference there either. The advantage here would be that there's no need to detect the virtual or backed nature of the property at compile time and the RFC would be a lot shorter. Thank you for your consideration! Best, Jakob --0000000000009d89d2061495ff31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 21, 2024, 19:57 Larry Gar= field <larry= @garfieldtech.com> wrote:
He= llo again, fine Internalians.

After much on-again/off-again work, Ilija and I are back with a more polish= ed property access hooks/interface properties RFC.=C2=A0 It=E2=80=99s 99% u= nchanged from last summer; the PR is now essentially complete and more robu= st, and we were able to squish the last remaining edge cases.

Baring any major changes, we plan to bring this to a vote in mid-March.
=

It=E2=80=99s long, but that=E2=80=99s because we=E2=80=99re handling every = edge case we could think of.=C2=A0 Properties involve dealing with both ref= erences and inheritance, both of which have complex implications.=C2=A0 We = believe we=E2=80=99ve identified the most logical handling for all cases, t= hough.

Note the FAQ question at the end, which explains some design choices.

There=E2=80=99s one outstanding question, which is slightly painful to ask:= Originally, this RFC was called =E2=80=9Cproperty accessors,=E2=80=9D whic= h is the terminology used by most languages.=C2=A0 During early development= , when we had 4 accessors like Swift, we changed the name to =E2=80=9Chooks= =E2=80=9D to better indicate that one was =E2=80=9Chooking into=E2=80=9D th= e property lifecycle.=C2=A0 However, later refinement brought it back down = to 2 operations, get and set.=C2=A0 That makes the =E2=80=9Chooks=E2=80=9D = name less applicable, and inconsistent with what other languages call it.
However, changing it back at this point would be a non-small amount of grun= t work. There would be no functional changes from doing so, but it=E2=80=99= s lots of renaming things both in the PR and the RFC. We are willing to do = so if the consensus is that it would be beneficial, but want to ask before = putting in the effort.

--
=C2=A0 Larry Garfield
=C2=A0 larry@garfieldtech.com

Hi, thanks for the RFC and the effort put= into trying to make it palatable to skeptical minds!

After reading most of the discussion in this = thread I believe that the RFC in its current form can work and that I will = get used to it's "peculiarities", but an idea occurred to me = that may have some advantages, so here goes:

Use the "set"=C2=A0keyword that you've already introduced to set the raw value of a= "backed" property:

public int $name {
        set {
             set strtoupper($value);
        }
    }
Or when used in short form:

public int $name {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 set = =3D> set strtoupper($value);
=C2=A0 =C2=A0 }
Advantages in no particular order:
1. Shorter= than=C2=A0$this->name
2. No magic=C2=A0$field=C2=A0
3. S= hort and long form works the same

Dis= advantage: "Set" can only be used to set the raw value inside the= hook method itself. Or maybe that's a good thing too. To be honest, I = don't love that $this->name sometime= s goes through the hook and sometimes not. I'd prefer if the raw value = could only be accessed inside the hooks or via a special syntax like f.ex. = $this->name:raw
<= br>If there are any use cases or technical details that I've missed tha= t=C2=A0would make this syntax unfavourable, I apologize.


Another= observation (I apologize for being late to the game but it was a long RFC = and thread to read through):

What would happen if we stopped talking= about virtual vs. backed properties? Couldn't we just treat a property= that was never set the same as any other uninitialized property?
What I mean is, that if you try to access the raw value of a property with= a set hook that never sets its own raw value, you'd get either null or=C2=A0Typed property [...] must not be accessed before initialization, ju= st like you'd expect if you're already used to modern php.=C2=A0Of course you'd just write yo= ur code correctly so that that never happens. It's already the case tha= t uninitialized properties are omitted when serializing the object so there= would be no difference there either.

The advantage here would be that there's no need to detec= t the virtual or backed nature of the property at compile time and the RFC = would be a lot shorter.

=
Thank you for your consideration!

Best,<= br>Jakob

--0000000000009d89d2061495ff31--