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

Should ether's BigNumber module support detection of BN.js numbers? #595

Open
sohkai opened this issue Sep 1, 2019 · 1 comment

Comments

@sohkai
Copy link

commented Sep 1, 2019

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.

@ricmoo

This comment has been minimized.

Copy link
Member

commented Sep 1, 2019

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. :)

@ricmoo ricmoo added the discussion label Sep 1, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.