Re: [RFC] [Discussion] Support object type in BCMath

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