It would be nice if the internal BigNumber constructor had a case to detect BN.js (and perhaps BigNumber.js) numbers. It currently throws if you pass in a BN.js number.
The module already uses BN.js in the back, and I'd consider a BN.js number to be "bignumberish".
In particular, I noticed this during the switch to the latest web3@1 from an older version of web3@1 (prior to web3's ABI module switching to ether's). You used to be able to pass in a BN.js number to its ABI encoder (and all other things built on top, e.g. contract calls and sends).
However, I can see how this could be a distinct design decision to abstract the big number aspects away from specific implementations to keep the API cleaner.
I’ve thought about this before, and early versions did support it, but the problem is there wasn’t really a reliable way to detect what was passed in was a BN.js or BigNumber.js.
The instanceof doesn’t work well, because often it is a slightly different version passed in, or after webpack or browserify a separate copy of the code.
Also detecting the methods like .mod and such lead to bizarre errors, when the user is using BigDecimal or such, in which case calling toString can result in values like “1.2”. Because it is otherwise a valid BigNumber-like interface, but then errors are sporadic since BigDecimal(“1.0”).toString() is “1”, but BigDecimal(“1.1”).toString() fails.
I’d love to support as wide a range of inputs as possible, but it is important to behave consistently and be unsurprising. :)
Closing this now, but please feel free to re-open if you'd like to discuss it further. :)
Thanks! :)
Most helpful comment
I’ve thought about this before, and early versions did support it, but the problem is there wasn’t really a reliable way to detect what was passed in was a BN.js or BigNumber.js.
The instanceof doesn’t work well, because often it is a slightly different version passed in, or after webpack or browserify a separate copy of the code.
Also detecting the methods like
.modand such lead to bizarre errors, when the user is using BigDecimal or such, in which case calling toString can result in values like “1.2”. Because it is otherwise a valid BigNumber-like interface, but then errors are sporadic since BigDecimal(“1.0”).toString() is “1”, but BigDecimal(“1.1”).toString() fails.I’d love to support as wide a range of inputs as possible, but it is important to behave consistently and be unsurprising. :)