Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118628
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-935-ge4ccd4c47b-fm-20220914.001-ge4ccd4c4
Mime-Version: 1.0
Message-ID: <c8dc0d92-a04d-4dd1-bf3e-5a05d3552409@www.fastmail.com>
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" <internals@lists.php.net>
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