Closed iamdoron closed 5 years ago
Hi, I'll have a look at this properly later this week.
Funny, I was coming here to create a similar request.
We are storing our application state as documents to mongoDB and we have a lot of use of BigNumber. When the documents are saved to Mongo bignumber objects are recorded as { s: number, e: number, c: [number], "_isBigNumber": bool }
within the database.
Having a BN constructor that allows creation from this would be hugely helpful to us when restoring our state from the db documents.
i.e., we need something like: new BigNumber({ s: number, e: number, c: [number], "_isBigNumber": bool })
You have defined the BigNumberData
interface within the BigNumber
namespace, so
BigNumber.BigNumberData
would be added to the existing exports:
// class BigNumber (default export)
// type BigNumber.Constructor
// type BigNumber.Instance
// type BigNumber.ModuloMode
// type BigNumber.RoundingMOde
// type BigNumber.Value
// interface BigNumber.Config
// interface BigNumber.Format
I would prefer
export interface Object {
so the export would be
BigNumber.Object
whicih seems more in keeping.
The alternative is to move the interface out of the BigNumber
namespace, but, on balance, I'd prefer to keep all the exported symbols within it.
I don't want any version property.
@jcramer
I'm not sure about requiring the "_isBigNumber"
property, as in bignumber.mjs (the ES module version of bignumber.js) it doesn't exist (a Symbol is used instead).
@MikeMcl
BigNumber.BigNumberData
to BigNumber.Object
. It does look better. I thought Object was a used keyword, but inside of a namespace it's OK.NaN
issueThere is also BigNumber Infinity which is {c: null, e: null, s: 1}
.
My preference is:
interface Object {
readonly c: number[] | null;
readonly e: number | null;
readonly s: number | null;
}
(--strictNullChecks
recommended.)
On balance, I prefer not to have the [key:string]: any;
, although I can see its appeal in terms of flexibility, so it is a very close call.
No need to export BigNumber.Object
.
BigNumber.Value
is enough.
export type Value = string | number | BigNumber | Object;
Thanks, Doron.
v8.1.1 released.
I went with the following in the end:
interface Instance {
readonly c: number[] | null;
readonly e: number | null;
readonly s: number | null;
[key: string]: any;
}
type Value = string | number | Instance;
To create a BigNumber from an object:
const n = { s: 1, e: 2, c: [ 777, 12300000000000 ], _isBigNumber: true };
const x = new BigNumber(n);
To check that a BigNumber instance is well-formed:
BigNumber.DEBUG = true;
BigNumber.isBigNumber(n); // true
BigNumber.isBigNumber(x); // true
See isBigNumber.
Hi,
BigNumber
is not yet stable (and might change forever), but I think we can defineBigNumberData
which is pretty stable:That will actually allow multiple packages to have different BigNumber versions, but still interact safely without converting to string. Nice thing about this way is that if you have
BigNumber7
&BigNumber8
,just works (presumably safely, even with breaking changes in BigNumber v8 that didn't change BigNumberData).
Maybe we can also version this
BigNumberData
if you believe it will change in the future. I didn't do it in this PR , but for example:and once ver is changed BigNumber will throw when trying to construct with unknown versions