Hi Barney, > Ah ok. Maybe that's the standard way internal classes are written, and we can > consider it generally an error for a child class to override the constructor > without calling `parent::__construct()`. I know tools warn users not to > forget the parent call.
Thanks, A fallback would be possible to always set the initial value to 0, but an error would probably be easier to understand. > And I had been thinking of BcNum as a readonly class, but I see it's not an > readonly class, it's a mutable class with its one and only property being > readonly. I agree that it seems unnecessary to force child classes to be > immutable - I wasn't concerned about them adding additional, mutable, > properties, only about leaving the value property uninitialized. (Btw I would > have supported the 1st part of the 2022 Readonly amendments RFC, which I > think would have made a readonly class behave the same as a class where every > property is readonly, particularly since would have allowed implementing the > example given on the Wikipedia page for LSP: a circle with fixed centre and > mutable radius may inherit from an immutable point) Ah, sorry about that, I completely forgot about the readonly class! In that case, it might make sense to make the classes completely immutable, since users are already accustomed to using such classes. This is a departure from what I said in my previous email, but how do you think about making it a read-only class? Regards. Saki
