> On 14 Nov 2022, at 03:08, Larry Garfield wrote:
>
> Hi folks. Ilija is nearly done with the implementation for asymmetric
> visibility and flushing out edge cases, but we've run into one design
> question we'd like feedback on.
>
> There's two design decisions we've made at this point, bot
On Sun, 13 Nov 2022, Larry Garfield wrote:
> There's two design decisions we've made at this point, both of which
> we think are logical and reasonable:
>
> 1. If specified, the set visibility must be tighter than the get
> visibility. So `protected protected(set)` and `protected public(set)`
On Mon, 14 Nov 2022, Stephen Reay wrote:
> As I understand it, you’re suggesting that a property declared as
> `public protected(set)` would never trigger __set().
I would think that that would be against our current practice, which is
easy enough to explain as "if the property isn't visible se
Hi Derick
> > As I understand it, you’re suggesting that a property declared as
> > `public protected(set)` would never trigger __set().
>
> I would think that that would be against our current practice, which is
> easy enough to explain as "if the property isn't visible set,
> then use __set()".
On Sun, Nov 13, 2022, at 4:08 PM, Deleu wrote:
>>
>>
>> This is untrue. You can declare a private property identically in a
>> parent and child class, even readonly. I'm doing this now in a project.
>> It works, but would be unnecessary if the parent's property were
>> protected(set).
>>
>> --Lar
>>
>> 1. Relax the set-is-tighter restriction. That would allow `protected
>> protected(set)` etc. on any property. It wouldn't be particularly useful
>> unless readonly is being used, but it would be syntactically legal and
>> behave as you'd expect. We could still disallow "set is more
Hi Everyone,
Following Nicolas' thread about "Issues with readonly classes" (
https://externals.io/message/118554), we created an RFC to fix two issues
with the readonly behavior: https://wiki.php.net/rfc/readonly_amendments
Please let us know your thoughts!
Máté
Hi,
> If my default assumption (and Larry's) was that such a class would be
immutable, it's fair to think that a non-trivial number of other
programmers may make the same faulty assumption, and making this
distinction obvious in the documentation would probably help.
Yes, it makes sense to mentio
