On Tue, Apr 2, 2024 at 1:47 PM Larry Garfield <la...@garfieldtech.com> wrote:
> > * Data classes protect from interior mutability. More concretely, > > mutating nested data objects stored in a `readonly` property is not > > legal, whereas it would be if they were ordinary objects. > > * In the future, it should be possible to allow using data classes in > > `SplObjectStorage`. However, because hashing is complex, this will be > > postponed to a separate RFC. > > Would data class properties only be allowed to be other data classes, or > could they hold a non-data class? My knee jerk response is they should be > data classes all the way down; the only counter-argument I can think of it > would be how much existing code is out there that is a "data class" in all > but name. I still fear someone adding a DB connection object to a data > class and everything going to hell, though. :-) > If there is a class made up of 90% data struct and 10% non-data struct, the 90% could be extracted into a true data struct and be referenced in the existing regular class, making it even more organized in terms of establishing what's "data" and what's "service". I would really favor making it "data class" all the way down. I understand you disagree with the argument against inheritance, but to me the same logic applies here. Making it data class only allows for lifting the restriction in the future, if necessary (requiring another RFC vote). Making it mixed on version 1 means that support for the mixture of them can never be undone. -- Marco Deleu
