Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

default rounding mode for round calls #60

Open
rbro opened this issue Mar 14, 2021 · 5 comments
Open

default rounding mode for round calls #60

rbro opened this issue Mar 14, 2021 · 5 comments

Comments

@rbro
Copy link

rbro commented Mar 14, 2021

I understand the default rounding mode cannot be changed for internally reducing values to a precision, but would it be possible to set a default rounding mode for calls to ->round()? In my case, I'd like to always use a different rounding mode, but it requires me to set the rounding mode on every call to round().

I use bignumber.js which has something similar:

https://mikemcl.github.io/bignumber.js/#rounding-mode

Or is there another way this can be done without having to remember to pass the rounding mode on every call to round()? One way I thought of was if I could extend the Decimal class and override the round method, but I see the Decimal class is defined as final.

Thank you for your help.

@rtheunissen
Copy link
Contributor

rtheunissen commented Mar 14, 2021

Setting a global default might interfere with other packages that also use decimal, unaware of your default, or unsuspectingly setting their own. The Javascript example sets it on that particular object, which isn't quite how it works here. The best way I can think of handling this is to create your own decimal class with an internal instance of Decimal that you forward all your calls to, except for the ones you want to override. You can explicitly do that for each one, or annotate with @mixin and use __call to magically forward.

The decision to make the class final is more for internal implementation benefits, much less to consider when inheritance is not on the table.

The 2.0 branch (which when I find the time and energy will become the documented, standard version) has a Number base class that can be extended so that you can use arithmetic operators on any number type that you define. Otherwise, by using composition in the way I'm suggesting you l
would lose those benefits that exist in the Decimal class (because you can't do operator overloading in userland).

@rbro
Copy link
Author

rbro commented Mar 14, 2021

Thanks for your feedback. Yes, I tried doing as you suggested with my own decimal class, but one of the reasons I like the php-decimal extension is the operator overloading vs doing bcadd($a, $b). I like your idea of having a Number base class - would that then effectively allow operator overloading in userland if you extend that class?

@rtheunissen
Copy link
Contributor

That's right, so the + operator for example would call the add method on the instance, exactly for situations like this. Hopefully this approach doesn't create any problems for anyone that I haven't considered.

@rbro
Copy link
Author

rbro commented Mar 22, 2021

That would be great if you could do that. I feel it could be a replacement for PECL operator which no longer works - http://pecl.php.net/package/operator.

@CreepPork
Copy link

I'd really like to see this implemented, because I have to constantly pass everywhere, either to round or toFixed, PHP_ROUND_HALF_UP to make it properly round up for currencies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants