> >> 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. >
It's very difficult to anticipate this. Here is a counter argument: About services: the best ones are of the functional sort; they don't hold any states and their dependencies are also pure functional units. Aka they're immutable and they're good candidates for readonly classes. About entities: e.g. Doctrine proxies them all. So no, I wouldn't say that services are the most common things to proxy, and that entities are the most common things to use readonly on... I hope this discussion illustrated why we should remove propagating readonly to child classes: it serves no purpose and it breaks a universal design pattern. There is no rationale that supports the current behavior. Mate, WDYT? Cheers, Nicolas
