Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:122507 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 58D0D1AD8F6 for ; Mon, 26 Feb 2024 20:21:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1708978904; bh=+VgIe3A+T11ftn8Dwkb01NCgWbebjsehokEj8bxD7zM=; h=Date:Subject:To:References:From:In-Reply-To:From; b=G6psXFTiep/H1TSHmUSMeKBFpk3yDBupso6vYpQkQwwTSDmD3d+XvwIprZyAIUPU4 h3AATreK2x1sD1mdGJXlPpwaD6ug1puK53uR9hNyUpCa16neVQ3cAAc6L55V0B5tlx N4LUUJsusdfGG1eyFgimZB2xbN4/QIqV8krRmHTCVgmfUJBIcsE3MpIAi7i0qHMCNR wHjPr+gPBX/BNV5o/cq6rr7epWKhMI5a8EvfZYzxfcwi7+Jb6olCXri+rNiKlaYbsl UjxJDhOxyFenrXNQACrJmtUdXX6ZObDjRiat9gyzKGShV+LcIwHgOwliNhNOz/+rxY u0fQLd2UjSpPw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 043BA18087A for ; Mon, 26 Feb 2024 20:21:43 +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.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,HTML_MESSAGE, SPF_HELO_NONE,SPF_PASS,T_KAM_HTML_FONT_INVALID,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 mta3.mail.genkgo.net (mta3.mail.genkgo.net [2.58.165.21]) (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 ; Mon, 26 Feb 2024 12:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=genkgo.nl; s=ge-k1; h=In-Reply-To:From:References:To:Subject:MIME-Version:Date: Message-ID:Content-Type:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=q74d+IegzWApRg3V77rnvZgdktlytRTngXCgOJBwtd4=; b=OVV5j1QMlGlnPVTtmuSTmSgIxU gPwy/NzJXow/315H3iM/BTtws3QUVjlDVCkL08c5XZz37fOneTCxWexwsIStnT78fYPinPm3JcI+O npd9KJEejscqTfpbkWoBHS3Xab45DbX+FPcX7QxLkJn++6qGAGejbgZsUT6vTjwzxEiLmxGS2AUYN dmDe8u0Wk7NOZcky/hKIP8/nZft8JpxQi6cyI2bCnkFXeqXgAL0yPFoIUcMejF+expEZFEcYhVUpF NsQr7TGv+Ifr/taCEksE9cx7GtqQXHt9K71Tq42Tvv6z3JBvCq2jShvCmwLYQxCMPgubUAugpHunK LntySNng==; Received: from [185.184.111.39] (helo=[192.168.16.250]) by mta3.mail.genkgo.net with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1rehTg-0003l8-13 for internals@lists.php.net; Mon, 26 Feb 2024 20:21:32 +0000 Content-Type: multipart/alternative; boundary="------------00kPFu8jOj5wkyGRc1Boy0E7" Message-ID: <95e93cb9-3ab0-4cf3-8ec5-83e74c9dd607@genkgo.nl> Date: Mon, 26 Feb 2024 21:21:31 +0100 Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2 Content-Language: en-US, nl-NL To: internals@lists.php.net References: <790b5b4e-f51b-4050-a12a-5fa903d0568f@app.fastmail.com> <52C6F501-8E23-42D7-8541-88A22AD79375@koalephant.com> <36e90d8d-d275-4ce9-9dd9-1e2422c6d3a9@app.fastmail.com> <2fdf1933-b51c-40cc-8d02-31899b96c71c@genkgo.nl> In-Reply-To: From: f.bosch@genkgo.nl (Frederik Bosch) This is a multi-part message in MIME format. --------------00kPFu8jOj5wkyGRc1Boy0E7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Rowan, Thanks for clearing up that the return value will be ignored. I understand better why that is (void = null). I do like the updated RFC better than the one with the $field variable to write to. My yield suggestion was an idea derived from that earlier $field write proposal, but I wanted to share it anyhow. I do note that $this->propName might suggest that the backing value is accessible from other locations than only the property's own get/set methods, because of $this usage. I would rather have a $field in get referring to the current value, and a $value in set referring to the passed value. So with the full name example:     public string $fullName {         get ($field): string => $field;         set ($value): string {             [$this->first, $this->last] = explode(' ', $value);             return $value;         }     } I think it would make absolutely clear that the backing value is only accessible in the local get/set scope. Regarding returning void=null, this is something that IDE and static analyzers already pick-up as an error. I think being stricter on that in this RFC would actually make sense, and treat void not as null. So with a slightly different full name example:     public string $fullName {         get ($field): string => $this->first . ' ' . $this->last;         set ($value): void {             [$this->first, $this->last] = explode(' ', $value); // real void, no value returned         }     } And why yield is magic, I do not get that. The word and the expression actually expresses that something is, well, yielded. yield is a word that is reserved in the language that serves the purpose of the problem. I would use it. It is even explainable that the set function is treated as a generator function. Regards, Frederik On 26-02-2024 20:39, Rowan Tommins [IMSoP] wrote: > On 26/02/2024 19:02, Frederik Bosch wrote: >> >> That's how it always has been, no? So in your example, short code >> abbreviated form would not work. One has to write a block. >> >>      public  string$fullName  {           set=> [$this->first,  >> $this->last]  =  explode (' ',  \ucfirst >> ($value));  // error, $fullName is a >> string, returning array >>      } >>        public  string$fullName  {           set{ >>              [$this->first,  $this->last]  =  explode >> (' ',  \ucfirst >> ($value));  // no error, not returning >>          } >>      } > > > I think the intention is that both the block and the arrow syntax > would have any return value ignored, as happens with constructors, for > example. Note that in PHP, there is actually no such thing as "a > function not returning a value", even a "void" function actually > returns null; so if the return value was treated as meaningful, your > second example would give an error "cannot assign null to property of > type string". > > However, as noted in a previous message, I agree that the short form > meaning "the value returned is saved to the backing field" is both > more expected and more useful. > > The "yield" idea is ... interesting. I think personally I find it a > bit too magic, and too cryptic to be more readable than an explicit > assignment. Opinions may vary, though. > > Regards, > -- Frederik Bosch Partner Genkgo logo Mail: f.bosch@genkgo.nl Web: support.genkgo.com Entrada 123 Amsterdam +31 20 244 1920 Genkgo B.V. staat geregistreerd bij de Kamer van Koophandel onder nummer 56501153 --------------00kPFu8jOj5wkyGRc1Boy0E7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi Rowan,

Thanks for clearing up that the return value will be ignored. I understand better why that is (void = null). I do like the updated RFC better than the one with the $field variable to write to. My yield suggestion was an idea derived from that earlier $field write proposal, but I wanted to share it anyhow.

I do note that $this->propName might suggest that the backing value is accessible from other locations than only the property's own get/set methods, because of $this usage. I would rather have a $field in get referring to the current value, and a $value in set referring to the passed value. So with the full name example:

    public string $fullName {
        get ($field): string => $field;

        set ($value): string {
            [$this->first, $this->last] = explode(' ', $value);
            return $value;
        }
    }

I think it would make absolutely clear that the backing value is only accessible in the local get/set scope. Regarding returning void=null, this is something that IDE and static analyzers already pick-up as an error. I think being stricter on that in this RFC would actually make sense, and treat void not as null. So with a slightly different full name example:

    public string $fullName {
        get ($field): string => $this->first . ' ' . $this->last;

        set ($value): void {
            [$this->first, $this->last] = explode(' ', $value); // real void, no value returned
        }
    }

And why yield is magic, I do not get that. The word and the expression actually expresses that something is, well, yielded. yield is a word that is reserved in the language that serves the purpose of the problem. I would use it. It is even explainable that the set function is treated as a generator function.

Regards,
Frederik


On 26-02-2024 20:39, Rowan Tommins [IMSoP] wrote:
On 26/02/2024 19:02, Frederik Bosch wrote:

That's how it always has been, no? So in your example, short code abbreviated form would not work. One has to write a block.

     public  string$fullName  {           set=>  [$this->first,  $this->last]  =  explode  <http://www.php.net/explode>(' ',  \ucfirst  <http://www.php.net/ucfirst>($value));  // error, $fullName is a string, returning array
     }
       public  string$fullName  {           set{
             [$this->first,  $this->last]  =  explode  <http://www.php.net/explode>(' ',  \ucfirst  <http://www.php.net/ucfirst>($value));  // no error, not returning
         }
     }


I think the intention is that both the block and the arrow syntax would have any return value ignored, as happens with constructors, for example. Note that in PHP, there is actually no such thing as "a function not returning a value", even a "void" function actually returns null; so if the return value was treated as meaningful, your second example would give an error "cannot assign null to property of type string".

However, as noted in a previous message, I agree that the short form meaning "the value returned is saved to the backing field" is both more expected and more useful.

The "yield" idea is ... interesting. I think personally I find it a bit too magic, and too cryptic to be more readable than an explicit assignment. Opinions may vary, though.

Regards,

--

Frederik Bosch

Partner


Mail:
Web: support.genkgo.com

Entrada 123
Amsterdam
+31 20 244 1920

Genkgo B.V. staat geregistreerd bij de Kamer van Koophandel onder nummer 56501153
--------------00kPFu8jOj5wkyGRc1Boy0E7--