Voting for Asymmetric Visibility is now open.
https://wiki.php.net/rfc/asymmetric-visibility-v2
The vote will end on 9 February, probably afternoonish in my timezone.
--
Larry Garfield
larry@garfieldtech.com
Voting for Asymmetric Visibility is now open.
https://wiki.php.net/rfc/asymmetric-visibility-v2
The vote will end on 9 February, probably afternoonish in my timezone.
That's a pretty long voting period...
Andreas Heigl
The vote will end on 9 February, probably afternoonish in my timezone.
That's a pretty long voting period...
It seems he meant the 9th of August.
Presumably the proposed PHP version is wrong?
Presumably the proposed PHP version is wrong?
No, this is still within the window to target 8.4.
--Larry Garfield
Voting for Asymmetric Visibility is now open.
https://wiki.php.net/rfc/asymmetric-visibility-v2
The vote will end on 9 February, probably afternoonish in my timezone.
--
Larry Garfield
larry@garfieldtech.com
Sigh. And of course I meant the voting will end on 9 AUGUST, aka, two weeks from today. (No idea where that came from.)
--Larry Garfield
Voting for Asymmetric Visibility is now open.
Hi Larry and Ilija,
Thank you for all your work on this RFC!
One part that doesn't make sense to me is this sentence near the end in the "Readonly is incompatible with inheritance" section:
With asymmetric visibility, the
readonly
usage here can be replaced withprotected protected(set)
orreadonly protected protected(set)
, avoiding the need to double-declare properties.
protected protected(set)
just removes readonly, and is the same as protected
, right? So couldn't such a change be done now without asymmetric visibility?
And the change to protected protected(set) readonly
as shown in the example also seems unnecessary, since earlier in the RFC it says that readonly will be changed to imply protected(set)
rather than private(set)
. So it seems that no change is needed to the abstract class here - the properties can remain protected readonly
, and the implementation can be simplified since readonly properties will now imply protected(set)
.
Or have I misunderstood something here?
Thanks,
Theodore
Voting for Asymmetric Visibility is now open.
Hi Larry and Ilija,
Thank you for all your work on this RFC!
One part that doesn't make sense to me is this sentence near the end in
the "Readonly is incompatible with inheritance" section:With asymmetric visibility, the
readonly
usage here can be replaced withprotected protected(set)
orreadonly protected protected(set)
, avoiding the need to double-declare properties.
protected protected(set)
just removes readonly, and is the same as
protected
, right? So couldn't such a change be done now without
asymmetric visibility?And the change to
protected protected(set) readonly
as shown in the
example also seems unnecessary, since earlier in the RFC it says that
readonly will be changed to implyprotected(set)
rather than
private(set)
. So it seems that no change is needed to the abstract
class here - the properties can remainprotected readonly
, and the
implementation can be simplified since readonly properties will now
implyprotected(set)
.Or have I misunderstood something here?
I believe in this case you're correct. That example was written early on, before we decided to expand readonly to protected(set) by default. I didn't realize that needed to be updated as well. Yes, in this case, the widening of readonly would also resolve that issue. protected protected(set)
would now be redundant, but not hurt anything, whereas protected private(set)
would have an effect. public public(set) readonly
would also be legal (though I don't personally know why you'd do that, there's no inherent reason to make it illegal).
--Larry Garfield
Voting for Asymmetric Visibility is now open.
https://wiki.php.net/rfc/asymmetric-visibility-v2
The vote will end on 9 February, probably afternoonish in my timezone.
I have now closed the vote on this RFC.
The final result is 24 Yes, 7 No, for a total of 77.4% in favor.
The RFC has passed. Thanks everyone for your participation and input. Ilija will get the PR merged soonish.
--Larry Garfield