Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124611 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 6B9491A00B7 for ; Fri, 26 Jul 2024 12:59:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1721998847; bh=y87PYyXwFiFaNYpNDdrRleCCtJ15zDRKNyTGljm5j2g=; h=In-Reply-To:References:Date:From:To:Subject:From; b=PO1MhWMnxvJrgbSAii/8uI9jBe7D5JmgoLSF/C5ljowTp9nc2OW/Pluu0GJJaXfi6 QHt0HYLXIf73Y3C8TlBOjDtgDSDaRDSc8BGR3vbl0luoKd4qyxcW/rDbjBI3BZ95uE XwEs41affd7NsxA8zZzQUICVttbmta69joNaTzpM2opxAZgpTkSudi14axXR6FVCDC TUFCAUv6zy5h6HZr/q71HmhSZ+TF2zScPGmMz1HXQUtvxU9ReejbrFN5IN8CK3BfE9 rtwdyW1OB5DmTJ4eIXXv/xVXlg9QbwfRhs7iirVU8MTdOiskp7iYzZNFMa8cYGbEad 96VMg8ScyQ0ag== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id EF32218003A for ; Fri, 26 Jul 2024 13:00:46 +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 autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from fhigh1-smtp.messagingengine.com (fhigh1-smtp.messagingengine.com [103.168.172.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 26 Jul 2024 13:00:46 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 3399F114019F; Fri, 26 Jul 2024 08:59:11 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute3.internal (MEProxy); Fri, 26 Jul 2024 08:59:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=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=fm1; t=1721998751; x=1722085151; bh=GSx1KZdw5z 5mC+v1q0ScaHdyM+Ux8NSDVHNO+fsQqiE=; b=Yrqb63Cs8D8oi48SBzVS6GcHd9 Zemm/lunclZ26cuSNTvBbTvTD8LOWMm4gTv1Uir5cbpuzAeyICcg5CPFciQJSZ4z G81FVQtFpGwwjpd6Lp80utC72anDup2kJih9gTGaD0B3LCKO8X0r8J2m6E5V+NFz NA+kylyFkYisQVP/hID+5xaWm8ozszbspNYLyupZbDeeoRbNyVVNk4UKZ8NWQUiy 49BQsNS8FUC7Q3AOa6Yz/VPvGD/Kp03dc+ZvkE5oA9KLz95tjKPe4EfrN3HImujG qRiuLqgMEyXcZiSxkpJhzR/mTu+cYX92Kg+Zi5rYQQkFf2movRHWeMyoM0tw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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= fm3; t=1721998751; x=1722085151; bh=GSx1KZdw5z5mC+v1q0ScaHdyM+Ux 8NSDVHNO+fsQqiE=; b=E0pPKqb90Fn1U34Mm2sJpxXiwqfRgJ627/OqNm7tKRZg K1ey/aBlqjCtyhB3Rjqqmq+PbG6Baks6Yem7xH3NuIuGl6Krxre/DWnu4a5lND54 P0ja28506/0vpFrYGKNgKove6+SjxgtGulebi7OF1Q1JUwAR5SSYREeSLD4lBCzs FOAZsbQiuJow+C9yNeri2B0d/xqnBSiyVd11Dhl34ldI5nBeIf/LzqrTE+U8P6I7 ZwHjJhoJ6pD/WLoDsP1W0372KfpxV2mfB60M2osqBLxUYL7QH/mRvwJliIqC7WVh eXaHZUi2mw+QUXfN3kwFyfGYxvZCqzuEY33/4cTYjA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrieehgdeitdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedftfhosgcu nfgrnhguvghrshdfuceorhhosgessghothhtlhgvugdrtghouggvsheqnecuggftrfgrth htvghrnhepfeefudfhudduieekkedugffhudfgleejgfekgefhvdeikeelvddvjeehteeg teegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprh hosgessghothhtlhgvugdrtghouggvshdpnhgspghrtghpthhtoheptd X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id B31CC15A0092; Fri, 26 Jul 2024 08:59:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-582-g5a02f8850-fm-20240719.002-g5a02f885 Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 Message-ID: <161d5b04-4d94-47e9-a248-61639d688381@app.fastmail.com> In-Reply-To: <4e7714cb-0d88-43f5-aa30-9adb799e0b28@seld.be> References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com> <66c4ac1c-b3d7-4b20-b986-1fe1a464f485@app.fastmail.com> <4e7714cb-0d88-43f5-aa30-9adb799e0b28@seld.be> Date: Fri, 26 Jul 2024 14:58:48 +0200 To: "Jordi Boggiano" , internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2 Content-Type: multipart/alternative; boundary=69237eddce364fb98269ec858beb99b0 From: rob@bottled.codes ("Rob Landers") --69237eddce364fb98269ec858beb99b0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 26, 2024, at 13:36, Jordi Boggiano wrote: > On 21.07.2024 11:21, Rob Landers wrote: >>=20 >> 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? >>>=20 >>> It was, a year and a half ago when Aviz was first proposed. The pre= ference was split, but leaned toward the prefix-style syntax. So we wen= t with that. I don't think we'll ever get everyone to want the same syn= tax, but we're using the one that was both somewhat more popular, and (a= s discussed in the RFC) arguably superior. >>>=20 >>> As the "comments in yield from" thread has shown, *any* even slight = change to PHP's syntax will require work from static analysis tools. Th= at's the nature of the problem space, regardless of the syntax specifics. >>>=20 >>> --Larry Garfield >>>=20 >>=20 >> Just to play devil=E2=80=99s advocate, it was also before we had prop= erty hooks who advertised itself as a way to =E2=80=9Cwrap and guard acc= ess to object properties=E2=80=9D but we are simply ignoring their exist= ence here. >>=20 > Just to compare them, because my initial gut feel was to say "yes plea= se just put this together with hooks".. >=20 > As far as I understand these would be the two options? >=20 > class C { > public protected(set) $answer { get =3D> 42; set =3D> { $this= ->answer =3D $value * 2; } > public private(set) $publicReadOnly; > } >=20 >=20 > class C { > public $answer { get =3D> 42; protected set =3D> { $this->ans= wer =3D $value * 2; } > public $publicReadOnly { private set; } > } >=20 > And now that I see it spelled out more, I do agree that while it appea= rs a bit more verbose, and this "(set)" looks odd at first, having all t= he visibility upfront is a lot clearer than having to read through the h= ooks to see what visibility applies. On a large property hook that potentially span hundreds of lines, I'd ra= ther only need to scroll up to the "set =3D>" to see how it is set vs. g= oing all the way back up to the property itself. --69237eddce364fb98269ec858beb99b0 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable

=

On Fri, Jul 26, 2024, at 13:36, Jordi Boggiano wrote= :
On 21.07.2024 11:21, Rob Landers wrote:

On Sat, Jul 20, 2024, at 23:51, La= rry Garfield wrote:
On Sat, Jul 20, 2024, at 7:22 AM, Rodrigo Vieira wrote:
<= /div>
> 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.

<= /div>
--Larry Garfield

Just to play devil=E2=80=99s advocate, it was also before we= had property hooks who advertised itself as a way to =E2=80=9Cwrap a= nd guard access to object properties=E2=80=9D 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 =3D> 42; set =3D> { $=
this->answer =3D $value * 2; }
         public private(set) $publicReadOnly;
     }


     class C {
         public $answer { get =3D> 42; protected set =3D> { $this-=
>answer =3D $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 hoo=
ks to see what visibility applies.

=
On a large property hook that potentially span hundreds of lines, I= 'd rather only need to scroll up to the "set =3D>" to see how it is s= et vs. going all the way back up to the property itself.
--69237eddce364fb98269ec858beb99b0--