On 29/06/2024 16:55, Ben Ramsey wrote:
If this RFC passes to make the \GMP class final, and your RFC passes to
allow extending the \GMP class, then I think we’re in a sort of weird
limbo state.
Presumably in that case whichever RFC passes last would have to take
precedence. The community is al
On Tue, 25 Jun 2024 17:29:58 +0100 Saki Takamachi wrote ---
>
> Also, it is not practical to record the remainder in the Number object
> resulting from the division. This is because there can be objects whose
> division results are equal but whose remainders are different.
>
On Tue, 25 Jun 2024 10:11:10 +0100 Saki Takamachi wrote ---
> Hi internals,
>
> I've been working on improving performance of BCMath lately, and I found
> that I can get the div and mod in one calculation. This is obviously faster
> than calculating it twice separately.
>
> Do
On 18/05/2024 15:00, Robert Landers wrote:
Hello internals,
I've been thinking about having an "internal" attribute that will emit
a warning if called from outside it's left-most namespace.
Hello Robert,
It's worth looking at the prior art on this - the @internal annotation
from PHPDoc, and
On 2024-04-08 12:17, Arvids Godjuks wrote:
Why not have decimal be represented as 2 64-bit ints at the engine
level
Just to clarify this point, what's the formula to convert back and
forth between a decimal and two integers? Are you thinking like
scientific notation: decimal = coefficient *
On 07/04/2024 11:07, Rowan Tommins [IMSoP] wrote:
On 7 April 2024 01:32:29 BST, Jordan LeDoux wrote:
Internals is just volunteers. The people working on BCMath are doing that
because they want to, the people working on scalar decimal stuff are doing
that because they want to, and there's no p
Hello,
There are currently two proposals being discussed - /native decimal
scalar type support/ and /Support object type in BCMath/
I've been getting involved in the discussion for the BCMath proposal,
but not paying as much attention to the native decimal thread.
But these seem like very s
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
On 05/04/2024 10:48, Tim Düsterhus wrote:
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\Nu
On 05/04/2024 01:20, Saki Takamachi wrote:
I don't think it will be possible to make a good Money class as a child of
this. BcNum is a read-only class, so if the constructor of BcNum is final then
the child class won't be able to take the currency as a constructor param, and
won't be able to
On 04/04/2024 22:10, Jordan LeDoux wrote:
On Thu, Apr 4, 2024 at 1:59 PM Barney Laurance
wrote:
Hi again,
On 27/03/2024 00:40, Saki Takamachi wrote:
Do we also need `toFloat` and `toInt` functions? Seems like using explicit
functions will be safer than casting.
For
On 04/04/2024 01:54, Jordan LeDoux wrote:
On Tue, Apr 2, 2024 at 5:43 PM Saki Takamachi 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 o
Hi again,
On 27/03/2024 00:40, Saki Takamachi wrote:
Do we also need `toFloat` and `toInt` functions? Seems like using explicit
functions will be safer than casting.
For toInt I'd expect an exception if the value is outside the range of possible
ints. For toFloat it might be nice to have a fl
On 03/04/2024 01:42, Saki Takamachi wrote:
If make a class final, users will not be able to add arbitrary methods, so I
think making each method final.
Right, if a class is not final but has only final methods (including
constructor) and no protected properties then it allows people to exten
On 2024-04-02 12:26, Saki Takamachi wrote:
Also, an idea occurred to me while reading your comments.
The current assumption is that a Number always holds a single value.
How if we made it so that it held two values? They are the numerator
and the denominator.
Then we'd have a rational number,
On 2024-03-24 13:13, Saki Takamachi wrote:
I want to start the discussion on the PHP RFC: Support object type in
BCMath.
Do we also need `toFloat` and `toInt` functions? Seems like using
explicit functions will be safer than casting.
For toInt I'd expect an exception if the value is outside
On 2024-03-26 11:35, Saki Takamachi wrote:
**I immediately reflected the above two points in my RFC** :D
Thanks, looks good.
One more suggestion - might it be worth adding a `format` function
to the new BcNum class? This would be similar to the existing
number_format function, but would avo
On 24/03/2024 13:13, Saki Takamachi wrote:
I want to start the discussion on the PHP RFC: Support object type in BCMath.
https://wiki.php.net/rfc/support_object_type_in_bcmath
One more suggestion - might it be worth adding a `format` function to
the new BcNum class? This would be similar to t
On 24/03/2024 13:13, Saki Takamachi wrote:
I want to start the discussion on the PHP RFC: Support object type in BCMath.
I work on OLTP application using BCMath for money, and I would like to
refactor to value objects (although we could also convert to using
ints), so this is very relevant to
On 24/03/2024 13:13, Saki Takamachi wrote:
I want to start the discussion on the PHP RFC: Support object type in BCMath.
I suggest renaming `setScale` to `withScale`. Although the docs will
make clear that the object is immutable, `set` is associated with
mutation and might be confusing. `wit
On 16/03/2024 05:22, Saki Takamachi wrote:
Yet another idea is to also support immutable objects, like DateTime.
e.g.
```
$num1 = new BcNum('1.235');
$num1imm = new BcNumImmutable('1.235');
$num2 = new BcNum('2.001');
$num1result = $num1->add($num2);
$num1immResult = $num1imm->add($num2);
I wou
21 matches
Mail list logo
