Re: Re: Issues with readonly classes
| From: | Larry Garfield | Date: | Sun, 11 Sep 2022 15:24:05 +0000 |
| Subject: | Re: Re: Issues with readonly classes | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-118607@lists.php.net to get a copy of this message | ||
On Sat, Sep 10, 2022, at 4:34 PM, Nicolas Grekas wrote:
>> Personally I'm undecided at the moment whether or not it should be
>> allowed. I'm sympathetic to the "it's easier to disallow and allow later
>> than vice versa" argument, but still not sure where I stand. The above at
>> least gives a concrete example of where the problem would be.
>>
>
> If we want the safety you describe, we might want a stronger version of it.
> Let's name it immutable. An immutable property/class would be like a
> readonly property with the additional restriction that only an immutable
> value could be assigned to it (scalars + array + immutable classes.) But
> that's another topic.
>
> Your example made me doubt for a moment, but without any convincing
> purpose, this should help decide that child classes shouldn't have to be
> readonly.
>
> Nicolas
Another question I think is pertinent to ask: What kinds of objects generally would be proxied in
this way, and are those the kinds of objects where a readonly object would make sense?
Off hand, I'd expect this kind of proxying to be used mainly on services, whereas readonly
classes would be mostly value objects. So the problem space may be smaller than it initially
appears.
--Larry Garfield