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
On Sun, Sep 25, 2022 at 10:57 AM Máté Kocsis wrote:
> Hi,
>
> I agree with Tim, and I also think that both reverting and making any last
> minute fundamental change is not a good idea, especially
> because people don't have a clear agreement about how inheritance
> should work. Readonly classes i
Hi,
I remembered the same thing, and am similarly baffled. How did the RFC pass
> if you can do something as simple as `public readonly stdClass $var;`? I
> thought I followed the discussion on that RFC, but apparently I missed
> something. I would have expected an example like above to block acce
On Tue, Sep 20, 2022, at 1:07 PM, Jordan LeDoux wrote:
> On Sun, Sep 11, 2022 at 8:22 AM Larry Garfield
> wrote:
>
>>
>>
>> Hm. I seem to recall during the discussion of readonly classes someone
>> saying that object properties of a readonly class had to also be readonly
>> classes, which would r
Hi
On 9/21/22 11:48, Nicolas Grekas wrote:
What's your take about 8.2? As I demonstrated, readonly classes are broken
because of this propagation to child classes.
s/broken/working as expected
broken. see thread
Working as expected (or: working as designed). The behavior with regard
to
>
> > When I was working on the readonly class RFC, I realized that the
>> readonly
>> > keyword very naturally fits services besides value objects. So my
>> > expectation has been that until we can fix the issue with cloning,
>> people
>> > would mainly apply readonly to services. Not that it is v
On Wed, 21 Sept 2022 at 11:30, Nicolas Grekas
wrote:
> Hi all,
>
>
> > When I was working on the readonly class RFC, I realized that the
> readonly
> > keyword very naturally fits services besides value objects. So my
> > expectation has been that until we can fix the issue with cloning, people
>
Hi all,
> When I was working on the readonly class RFC, I realized that the readonly
> keyword very naturally fits services besides value objects. So my
> expectation has been that until we can fix the issue with cloning, people
> would mainly apply readonly to services. Not that it is very usefu
On Sun, Sep 11, 2022 at 8:22 AM Larry Garfield
wrote:
>
>
> Hm. I seem to recall during the discussion of readonly classes someone
> saying that object properties of a readonly class had to also be readonly
> classes, which would render the above code a compile error. However, I
> just checked
Hi Nicolas, Larry,
Mate, WDYT?
>
When I was working on the readonly class RFC, I realized that the readonly
keyword very naturally fits services besides value objects. So my
expectation has been that until we can fix the issue with cloning, people
would mainly apply readonly to services. Not that
> >> 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 b
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
On Sat, Sep 10, 2022, at 4:34 PM, Nicolas Grekas wrote:
> Hello Larry,
>
>
>> Regarding your main question: I understand your problem with readonly
>> > classes, and I'd be happy if we found a solution which fits your
>> use-cases
>> > and keeps consistency for the engine at the same time. To give
Hello Larry,
> Regarding your main question: I understand your problem with readonly
> > classes, and I'd be happy if we found a solution which fits your
> use-cases
> > and keeps consistency for the engine at the same time. To give you more
> > context about the inheritance related restriction i
On Mon, Sep 5, 2022, at 4:01 AM, Máté Kocsis wrote:
> Regarding your main question: I understand your problem with readonly
> classes, and I'd be happy if we found a solution which fits your use-cases
> and keeps consistency for the engine at the same time. To give you more
> context about the inh
Hi Mate
For 2.: static properties are useful e.g. to cache some shared state (info
>> extracted from reflection in my case) and I really don't see why readonly
>> classes should forbid static properties. Readonly is only useful for
>> instances, because it gives them immutability, but what's the l
Hi Nicolas,
For 2.: static properties are useful e.g. to cache some shared state (info
> extracted from reflection in my case) and I really don't see why readonly
> classes should forbid static properties. Readonly is only useful for
> instances, because it gives them immutability, but what's the
17 matches
Mail list logo
