On Fri, Jan 6, 2023, at 5:37 PM, Larry Garfield wrote:
> I am hereby opening the vote on the Asymmetric Visibility RFC: 
>
> https://wiki.php.net/rfc/asymmetric-visibility
>
> Voting will be open for 2 weeks.
>
> While we would certainly prefer if everyone voted in favor, for those 
> who vote against the authors kindly request that you indicate why, 
> using the second poll question or comment section afterward.  Thank you.

Hi folks.  Two brief things I want to mention as they have come up in other 
discussion:

First, I mentioned this in my reply to Nicolas, but it could easily have gotten 
buried:

Based on the fore-work that Ilija has done on property hooks in the last 3-ish 
weeks, we feel confident in saying:

1. Hooks will most likely not be practical on array properties at all.
2. That means if asymmetric visibility were to use hook-style syntax, 
asymmetric visibility would not be supported on arrays.

That is the final nail in the coffin for that approach, in our view.  We can 
have asymmetric visibility on array properties, or we can use C#-style 
hook-based syntax for it.  We cannot (reasonably) have both.  Given that, we 
feel very firmly that the current proposal (Swift style) is the only feasible 
syntax to use for asymmetric visibility.

Second, Theodore Brown noted on the RFC in the comments section (thank you):

"Proposal feels unfinished since it can't be used in conjunction with readonly 
properties/classes. In my opinion the issues with this need to be resolved 
first, to avoid the language moving towards a messy hodgepodge of features that 
don't work well together."

We are confident that readonly and a-viz can be combined in the future.  It's 
not a "messy hodgepodge".  However, there is a design question around 
same-visibility and readonly that was discussed in a previous thread (named 
"Asymmetric visibility, with readonly"), and the consensus there was to hold 
off on that question until later.  So, we're following the consensus.  In 
particular, we're keeping future options open in order to ensure that we don't 
end up with a "messy hodgepodge."  Without a clear consensus on exactly how 
that should behave, holding off on it and keeping our future options open is 
the smarter, more responsible approach.

--Larry Garfield

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

Reply via email to