Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122964
Content-Type: multipart/alternative;
 boundary="------------uusMmLqQF0Gt8lhFy5AxhVQd"
Message-ID: <65bac481-628b-49c0-a87e-b54dd466fc0f@redmagic.org.uk>
Date: Fri, 5 Apr 2024 12:02:41 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
To: internals@lists.php.net
References: <5876c04a-bfed-4a97-be65-f8b64ddef31a@redmagic.org.uk>
 <1F912518-DE28-4E83-B9AA-AC135822B306@sakiot.com>
Content-Language: en-US
In-Reply-To: <1F912518-DE28-4E83-B9AA-AC135822B306@sakiot.com>
From: barney@redmagic.org.uk (Barney Laurance)

This is a multi-part message in MIME format.
--------------uusMmLqQF0Gt8lhFy5AxhVQd
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


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.

--------------uusMmLqQF0Gt8lhFy5AxhVQd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 05/04/2024 09:37, Saki Takamachi
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1F912518-DE28-4E83-B9AA-AC135822B306@sakiot.com">
      <pre class="moz-quote-pre" wrap="">Hi Barney,

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">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.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Thanks, A fallback would be possible to always set the initial value to 0, but an error would probably be easier to understand.</pre>
    </blockquote>
    <p>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.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:1F912518-DE28-4E83-B9AA-AC135822B306@sakiot.com">
      <pre class="moz-quote-pre" wrap="">


</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">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)
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
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?</pre>
    </blockquote>
    <br>
    <p>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.<br>
      <br>
    </p>
    <p><span style="white-space: pre-wrap">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.
</span></p>
  </body>
</html>

--------------uusMmLqQF0Gt8lhFy5AxhVQd--