Currency outputs exchange rates as floats, because those are application-neutral (Integer notations for decimal values are more application-specific). However, floats have their own quirks (loss of precision). A solution to both problems would be to output decimal values as strings, but in a decimal notation. As Currency does not do computations, but only passes on data, this should ensure data integrity and application-agnosticism.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | currency_1937356_02.patch | 1.67 KB | xano |
| #3 | currency_1937356_01.patch | 58.19 KB | xano |
| #1 | currency_1937356_00.patch | 15.99 KB | xano |
Comments
Comment #1
xanoUpdated all the tests and most of the code. To-dos:
- Update bartfeenstra/currency with string exchange rates
- Remove calculating reverse exchange rates
- Find a way for Currency::getRoundingStep() to return something else than a float, and to use that return value to round amounts. Consider removing the rounding feature completely. Calculating the rounding step may actually be useful enough to keep.
- Update validating for the currency_amount form element.
- Update database columns that are still floats.
Comment #3
xanoThe patch includes a composer update for bartfeenstra/currency, which partly explains the size.
Comment #4
xanoComment #5
xanocurrency_form_currency_amount_validate() compares values as strings instead of using bccomp().
Comment #6
xanoComment #8
xano#6: currency_1937356_02.patch queued for re-testing.
Comment #9
xanoComment #11
xano