> I'd like to reiterate my answer then: I think your idea and my proposal > doesn't try to solve the same problem. >
Like you write in the RFC: > Although actually “write-once” properties and property accessors are orthogonal to each other, it's arguable whether we still needed “write-once” properties if we had property accessors. Both proposals relate a lot to each other: it's one or another, both cannot coexist: there is only one meaning for the "readonly" keyword once it's bound to some interpretation. > once a “write-once” property is initialized, it can't be changed after cloning > The solution could be to add support for either object initializers or property mutation *during* the clone operation I think this is my biggest issue: it is very common to write immutable VOs with "withers" on them (see PSR-7). Thus the RFC doesn't address the currently most common way of writing immutable VOs I fear. I would be very interested in having at least a draft of the possibilities you have in mind because I don't get the suggestion you make in the RFC right now. Having a better clue about this might remove at least part of my concerns. I think this sentence in the RFC sums up the "why" quite nicely: > The only problem with solely relying on property accessors is that they can't prevent changes in the private/protected scope (depending on visibility). In short, the RFC builds on the idea that preventing changes to private/protected scope is worth the listed limitations: > this RFC proposes to disable the property modifier in question for [untyped properties] > Another restriction of “write-once” properties is that they can't have a default value > “write-once” properties must not override regular properties While "property accessors-like" would have none of them if I'm not wrong, and would solve the "withers" use case. That's where we have a different judgment IIUC: to me, visibility-bound read-only access provides all the conceptual guarantees we need: - as class authors: "don't mess up with my state, you, userland"; - and from userland: "I trust you to know how to deal with your internal state, you, class author". >From a static analysis pov, all would be plain explicit and could be verified automatically. Not internal-immutability of course. Note that I'm just arguing that the extra guarantee you look for might not be worth the downside. If there is a way to provide private-scope guaranteed immutability without the listed drawbacks, my concerns would void (thus my request for precisions about cloning.) Nicolas PS: the RFC doesn't mention anything about Reflection-based mutability. It could be worth adding something since we talked about it on the list: "ReflectionProperty::setReadOnly()"
