Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118628 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 22727 invoked from network); 14 Sep 2022 18:36:38 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 Sep 2022 18:36:38 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 74E181804C4 for ; Wed, 14 Sep 2022 11:36:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-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,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS29838 64.147.123.0/24 X-Spam-Virus: No X-Envelope-From: Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 14 Sep 2022 11:36:36 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 442003200A51 for ; Wed, 14 Sep 2022 14:36:31 -0400 (EDT) Received: from imap50 ([10.202.2.100]) by compute2.internal (MEProxy); Wed, 14 Sep 2022 14:36:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= garfieldtech.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to; s=fm2; t=1663180590; x=1663266990; bh=c+PHvvqUju2ZIDLpa5B15MRUJ OpY2CXA8gTnbwIdQR0=; b=HGyw6pvVw1pO+1N3SqsFdxdozoSqSTTfWm2ZRmenZ KjWn7j3O+/TO1P661xLx8UxXhJLnHFlblOml6d7dzqkyutBoZaBZNaaUQO6anXVY hiCKHSen7tcVVik3NyR7aAh2WAxkUsYJIPiN8uBDDIRM1nJV5xslYMuhigGTVMGj gQDHR5LfSlF4pPO1yJXS/hMoaCL/CAKOfq0nFh2S4GBHCH8+ir7IgR5s4RbzAAIB bqf2C6yzpEEAB3nd7vORnzgXxipeTN1NkrdKZJT6GFTCLmi4q/bUSmf2D0s1Kg3+ Ey8Yc27pY3TMeWcSHa6NIarAtL/KTwCUFpL3srLBXPjGQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1663180590; x=1663266990; bh=c +PHvvqUju2ZIDLpa5B15MRUJOpY2CXA8gTnbwIdQR0=; b=bk6Hz22kvVFEoLkKm pUQe4timi5m+GksmDnS8REn1eMJVOWKF52P8ueXpKZpeC9fXf7o+Wfu7xrFGJ63Q lCEiwrHLvO4YUt3B0BulZ8Hqxw53OK14I7ow4q6KouFSIAtKlivJdCNBMYWXodaM HTeeZV2p8EZueldox4mgKCClcI4I9h4qGwpLZDT3MuWph3HPKQ2rer5eOuj0CXGB 8/GntM3bCHVXD8eSrYCT3NgDhY72z7DTaNNSEeaJPyA0RHY+w1DANt2duYYZSmQB gzxeo9kLUxFW8+en5tu7J044wwRY6wDapr24XjYCuHd6Mwssp3IyULuD3uYJYGyM EybbA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeduiedgudeftdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfjughrpefofgggkfgjfhffhffv ufgtgfesthhqredtreerjeenucfhrhhomhepfdfnrghrrhihucfirghrfhhivghlugdfuc eolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtohhmqeenucggtffrrghtthgvrhhn peegveeujeekheegveekleekgeehjeejueeiveffgfeffeelfeeugfekudffhfefieenuc ffohhmrghinhepghhoohhglhgvrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomheplhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtoh hm X-ME-Proxy: Feedback-ID: i8414410d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9AD831700086; Wed, 14 Sep 2022 14:36:30 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-935-ge4ccd4c47b-fm-20220914.001-ge4ccd4c4 Mime-Version: 1.0 Message-ID: In-Reply-To: <879a586d-6ec4-438b-828c-48fa65e7e7a5@www.fastmail.com> References: <879a586d-6ec4-438b-828c-48fa65e7e7a5@www.fastmail.com> Date: Wed, 14 Sep 2022 13:35:53 -0500 To: "php internals" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC][Poll] Asymmetric Visibility and Accessor syntax From: larry@garfieldtech.com ("Larry Garfield") On Sat, Sep 3, 2022, at 5:38 PM, Larry Garfield wrote: > In case some people didn't see it in the previous thread, I am bumping=20 > this poll: > > https://docs.google.com/forms/d/e/1FAIpQLSefq15VvGNIXSnQaMTl3RW451w0E8= oesny8c4PLqmKl8HhQ-Q/viewform > > This is an informal poll on behalf of Ilija and I to determine the=20 > syntax pattern we end up using for both Asymmetric Visibility and=20 > Property accessor hooks. We in particular want to get feedback from=20 > RFC voters, because as we all know "discussion on the list" is=20 > frequently highly unrepresentative of the actual voter sentiment, and=20 > finding out "I like the idea just not that particular syntax" after a=20 > vote fails, well, sucks for everyone. > > If you are planning to vote at all on either RFC, please take a few=20 > moments to read the question being asked and give us feedback so we ca= n=20 > produce something acceptable to the broadest number of people. Hi folks. I've now closed the previous poll regarding asymmetric visibi= lity and have some results. =20 Total responses: 33 Voter responses: 11 ## Question 1 This question asked people to scale-rate between Swift-style (1) and C# = style (7). The final counts were: 1: 6 2: 7 3: 4 4: 4 5: 3 6: 3 7: 6 Which roughly translates as "opinions are very split and all over the ma= p, *but* there is a notable lean toward Swift-style." In particular, th= ere were 13 "Strongly or very strongly Swift" responses to 9 "Strongly o= r very strongly C#" responses, and the middle responses also leaned slig= htly Swift-style. Looking at the text responses people gave (thanks!), there were a sizabl= e number of supporters of either model that said it "just felt better" o= r "feels more natural" for subjective reasons. Much of the C# support c= ame from the fact that more PHP developers seem to also have C# experien= ce than Swift experience, so there was simply a familiarity question at = play. (Which is relevant, to be clear.) Among the non-feel comments, most were critical of the added user-facing= complexity of C# style in PHP (because of references), and therefore fa= vored Swift. If we restrict the results to just people with voting access, we get an = average rating of 3.909, or almost a perfect tie. (Figures.) =20 Based on the above, Ilija and I plan to continue on with Swift-style syn= tax. Although it is not universally preferred, it does seem to have som= ewhat stronger support and more cleanly separates the two features synta= ctically, as they are orthogonal to each other. ## Question 2 The next question was what syntax to use for the set-visibility, which w= as conducted with an RCV model. I computed the results using a slightly= modified version of Derick's counter that is used for RFC votes. (I ju= st tweaked it to take in data from the Google Form rather than the Wiki'= s output format. The counting engine is unchanged.) I was really surprised at the results. In the first round, `private(set= )` had a plurality lead over `public(set: private)` in second place: Candidate 'private(set)': 12 =E2=86=92 1 2 4 8 12 13 22 25 27 28 29 30 Candidate '(set: private)': 9 =E2=86=92 3 10 17 19 20 21 24 26 31 Candidate 'public private': 5 =E2=86=92 7 9 14 16 23 Candidate 'private:set': 3 =E2=86=92 0 5 6 Candidate 'public:private': 3 =E2=86=92 11 15 18 I really expected `private:set` to do better, given how many people seem= ed to be anti-parentheses, yet the top two responses were the ones with = parentheses. From examining the votes, `public(set: private)` was very = much a "love it or hate it" response. The rest of the rounds confirmed = the same results: Round 2: Candidate 'private(set)': 12 =E2=86=92 1 2 4 8 12 13 22 25 27 28 29 30 Candidate '(set: private)': 9 =E2=86=92 3 10 17 19 20 21 24 26 31 Candidate 'public private': 6 =E2=86=92 7 9 14 16 23 15 Candidate 'private:set': 5 =E2=86=92 0 5 6 11 18 Round 3: Candidate 'private(set)': 13 =E2=86=92 1 2 4 8 12 13 22 25 27 28 29 30 6 Candidate '(set: private)': 11 =E2=86=92 3 10 17 19 20 21 24 26 31 5 18 Candidate 'public private': 8 =E2=86=92 7 9 14 16 23 15 0 11 Round 4: Candidate 'private(set)': 20 =E2=86=92 1 2 4 8 12 13 22 25 27 28 29 30 6= 7 9 14 16 15 0 11 Candidate '(set: private)': 12 =E2=86=92 3 10 17 19 20 21 24 26 31 5 18 = 23 And so the consensus result is indeed `private(set)`, much to my surpris= e. Running the count on just voters gave the same end result. Looking at the comments, there were again a plethora of entirely subject= ive responses supporting, well, everything. Several people did note tha= t the explicit options (that had the word `set` in them somewhere) were = better, because explicitness, and because it allows them to be abbreviat= ed and/or used in an arbitrary order. We are therefore going to proceed with `public private(set)`, the same s= yntax as Swift and the current RFC text use. Thank you everyone for your participation. The results clearly show tha= t not everyone is going to be happy with the outcome no matter what, but= I hope that going through this poll and sharing this level of transpare= ncy ensures that at least most people feel heard and that their viewpoin= ts were considered. We'll be back with an updated RFC as previously discussed as soon as Ili= ja is able to make it all work. --Larry Garfield