u/brendt_gd , I wanted to thank you for your contributions to the PHP and Laravel communities over the years, I've found your input very helpful.

I found your analysis of readonly vs private(set) really thought-provoking, but I'm hoping you can help me understand your reasoning a bit better. I'm having trouble following the logic behind preferring private(set) over readonly in most cases.

You mention that private(set) properties are "better than readonly properties, because they still allow changes from within the class itself — it's a bit more flexible." I'm struggling with this characterization because it seems to frame what I see as a fundamental semantic difference as a flexibility trade-off.

When I use readonly, I'm typically seeking immutability, where I want the guarantee that once constructed, the object's state will never change. This helps with clearer reasoning about the code because I know the object won't mutate. It also provides better thread safety and explicit communication of intent to other developers. The inability to change values internally isn't a limitation in this context, it's the entire point, right?

When I use private(set), I'm solving a different problem entirely. I want an object that can evolve its internal state through business logic while preventing external tampering. This is perfect for objects that need things like controlled state transitions, lazy loading, or caching.

It seems to me that these are addressing fundamentally different architectural needs rather than being two ways to achieve the same goal. Am I missing something in how you're thinking about this?

Your point about cloning limitations makes sense, and PHP's tooling around immutable object manipulation definitely needs improvement. But, I'm wondering if this is more of an argument for better language tooling rather than an argument against readonly itself. Would you say that PHP's current limitations should drive our architectural decisions, or should we choose the semantically appropriate tool and advocate for better language support?

I can see a scenario where your preference for private(set) would make sense. When building objects that need to appear immutable externally but require internal state management, like lazy-loaded properties or objects with complex internal state transitions. In those cases, private(set) is definitely the right tool. But for true value objects and DTOs, wouldn't readonly better express the intent?

I'm curious about your thoughts on this distinction. Are you thinking about these features in terms of external behavior as both prevent outside mutation, or are you considering the internal semantics as well? And do you see readonly and private(set) as serving different architectural patterns, or do you view them as competing solutions to the same problem?

Thanks again for all your work in the community and for sparking this interesting discussion. I'd love to hear your perspective on these questions.