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

From: Date: Fri, 05 Apr 2024 11:02:41 +0000
Subject: Re: [RFC] [Discussion] Support object type in BCMath
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-122964@lists.php.net to get a copy of this message
On 05/04/2024 09:37, Saki Takamachi wrote:
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.
Uninitialized is miles better than 0 I think. 0 is a meaningful number just like any other and we should very strictly avoid inserting made up numbers into people's applications. Let them fail fast, not output fake data. I'd rather my web shop crashes than gives things away for free.
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?
Tim has convinced me that it should be a final class, in which case there's no meaningful distinction between a readonly class and a class with no mutable properties. In that case just for simplicity I'd say it should be a readonly class. If it's not a final class I think I'm not the right person to ask, since as I said I don't really like the fact that a readonly class behaves any differently to a class with no mutable properties. I prefer the behavior of the latter.

« previous php.internals (#122964) next »