Hi

>> The vote has now closed.
>> 
>> The final result is 14 Yes, 12 No, which is less than the required 66%.
>> The RFC is declined.
>> 
> 
> Highly interesting to see that there's a theoretical path with a different
> syntax that takes 4 voters to yes and change the outcome to 18/26, which
> would have been an approved RFC. Working with readonly nowadays I can kinda
> see how a-viz would be nice, but if I had a vote I'm also in the camp that
> didn't like the syntax.

There was a poll during the discussion phase on syntax.
https://externals.io/message/118557

So, there are two potential scenarios for what happened.

1. Enough people participated in the poll for a representative result
(unlikely, there were only 11 people with voting karma in the poll) and
this truly is the preferred syntax.
2. Not enough voters participated and the result is inaccurate. At this
point there's really nothing we could've done. We asked for feedback in
the RFC but didn't get any when it comes to syntax. I also contacted all
people who voted no due to syntax but only got one response. So even now
it's hard to understand if there's consensus on the preferred syntax for
the no-due-to-syntax voters.

IMO (not speaking for Larry here) this is a failure of the RFC process.
Voters dislike secondary votes that aren't purely additive, thus making
syntax a secondary vote wasn't really an option. However, many voters
also don't participate in the discussion or read the RFC until the vote
is announced. This makes it extremely difficult to understand the
majority opinion.

To be honest, I couldn't care less about what syntax is chosen. There
are semantic differences between the Swift and C# approach that matter,
as the C# approach makes working with arrays unnecessarily difficult.
Sadly this discussion drowned which became evident by answering the same
question repeatedly. Apart from that, any option would've done.

I'm not sure if this is something we can improve in the RFC process. We
don't want to discourage no votes just because people have limited time
to participate. Nonetheless, weeks of work going down the drain for
superficial reasons is also frustrating. Maybe something we could
implement is requiring a rationale when voting against an RFC.

I hope people who voted no due to syntax can still share their preferred
option so that we know if this is worth revisiting in the future. Larry
and I are also starting work on property hooks (a.k.a. accessors) at
which point it might become more evident why asymmetric visibility is
useful in the first place.

Ilija

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to