Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122960
Message-ID: <8035a2b2-f8dc-4a25-98eb-1d19c986bc75@bastelstu.be>
Date: Fri, 5 Apr 2024 11:48:57 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
To: Jordan LeDoux <jordan.ledoux@gmail.com>, Saki Takamachi <saki@sakiot.com>
Cc: Lynn <kjarli@gmail.com>, Aleksander Machniak <alec@alec.pl>,
 php internals <internals@lists.php.net>
References: <4F094EDA-5058-407D-AF39-06FD934FDE1F@sakiot.com>
 <bbcff629-4dd6-bc50-ac9f-641849dc218a@php.net>
 <68CF373E-6ABF-4471-8992-813B4BA1B508@sakiot.com>
 <904197f4-afb5-401e-9e17-7a655c5449d0@alec.pl>
 <CAMrTa2EK6ymBQuxeFj7tMV0M2crqCCCR=mLN-FSfuCgrQHEZ6A@mail.gmail.com>
 <AB663F3F-A888-45F7-B19A-00530A4EDB0C@sakiot.com>
 <CAMrTa2HOEUWQcPdZE3FZ9JWCS1DWuRTNhhfqGGZOmr=v1Mctdw@mail.gmail.com>
 <CANS-=pfVuKKfAiu0LUJTrEPnSRaa_nHwJCgMvSORruAwHMsvQg@mail.gmail.com>
 <CAMrTa2HXD+62TKbaaA-v-mct5zdR5ortUAbtG1R1D22amAgpNA@mail.gmail.com>
 <CAMrTa2GaK3AUp0WodhNO8RdvoLbbiCk14Gs2oWF6vEs_+qMYNg@mail.gmail.com>
 <655FEA80-9AB4-4AAD-A310-70ED968C97A2@sakiot.com>
 <CAMrTa2Fh_-M_Kezi7s_4P4+a+dTyKq=RExd6ARPRDqZYS175kA@mail.gmail.com>
 <CAMrTa2FrkvNPK6kETNJFNNDn0mL5dxkV=PmdxsysruhhjY=Uig@mail.gmail.com>
 <8FB87901-02D7-4934-9119-55B21CEDDA9D@sakiot.com>
 <CAMrTa2EJf2NK2D3J=q7xkAVuNKsjEBDVv+RDmxp_g9DSsjRgwg@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAMrTa2EJf2NK2D3J=q7xkAVuNKsjEBDVv+RDmxp_g9DSsjRgwg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 4/4/24 02:54, Jordan LeDoux wrote:
>> If make a class final, users will not be able to add arbitrary methods, so
>> I think making each method final. Although it is possible to completely
>> separate behavior between method and opcode calculations, this is
>> inconsistent and confusing to users and should be avoided.
>>
> 
> 
> Right, if a class is not final but has only final methods (including
>> constructor) and no protected properties then it allows people to extend it
>> but not break any encapsulation or (I think) impose any more BC
>> requirements on the maintainer (unless we care about conflicting with
>> method names of child classes when updating). It lets people just do
>> something a bit like adding 'extension methods' in C#. I like it. People
>> could write e.g. `$bcChildNumber->isPrime()` instead of
>> `BcNumberUtils::isPrime($bcNumber)`
> 
> 
> Yeah, I suspect the most common child class will be something like "Money"
> that additionally has a parameter denoting what currency the value is in,
> since that is by far the most common use case for arbitrary precision math
> in PHP. Making the calculation methods final should do fine in my opinion.

Your `Money` example would allow for unsound and/or non-sense behavior, 
such as:

     $fiveEuros = new Money(5, 'EUR');
     $tenDollars = new Money(10, 'EUR');

     $what = $fiveEuros + $tenDollars;

What would you expect to be in $what? A `BcMath\Number(15)`?

----------------

The BcMath\Number class *should* absolutely be final, as a number is a 
number is a number. Allowing extension just to be able to write 
$number->isPrime() instead of isPrime($number) will allow for very 
confusing code, such as the example above, with no way to work around it 
in userland. It also makes interoperability between two different 
libraries that expect their own extensions to work very painful.

Consider the following example:

     class PrimalityTestingNumber extends Number {
         public function isPrime(): bool { }
     }

     class ParityTestingNumber extends Number {
         public function isEven(): bool { }
         public function isOdd(): bool { }
     }

If I now want to create a function to check whether a number is an even 
prime, I need to do something like this:

     function isEvenPrime(Number $n) {
         return (new PrimalityTestingNumber($n))->isPrime() && (new 
ParityTestingNumber($n))->isEven();
     }

This use case would be much better solved in a generic way using 
something like this "Extension Methods" proposal: 
https://externals.io/message/118395#118395

Best regards
Tim Düsterhus