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
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é
>>
>> 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
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
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 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
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 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