A noConflict method about bignumber.js HOT 17 CLOSED

I will consider this.

Alternatively, amending the library as shown below would allow multiple, independent BigNumber objects to be created.

;(function ( global ) {
    'use strict';

    function BigNumberFactory() {                                       // Added  
        var MAX = 1E9... 
        ...

        return BigNumber;                                               // Added  
    }                                                                   // Added  

    var BigNumber = BigNumberFactory();                                 // Added  
    BigNumber['anew'] = function () { return BigNumberFactory(); };     // Added  

    if ( typeof module !== 'undefined' && module.exports...
    ...
})( this );    

Usage:

var BN = BigNumber.anew();

BigNumber.config(3);
BN.config(6);

console.log( BigNumber(1).div(3).valueOf() );   // 0.333
console.log( BN(1).div(3).valueOf() );          // 0.333333

from bignumber.js.

That certainly looks like it would work for me. :)

from bignumber.js.

The way I am working around this is to include the bignumber.js (@@BigNumber) source in my project. Then I have a private copy that is not affected by a users config.

    function addBigNumberModule(module, define) {
        if (!isUndefined(module) || !isUndefined(define)) {
            throw new Error();
        }

        /*jshint validthis:true */
        /*@@BigNumber*/

        return this.BigNumber;
    }

and then my UMD looks like this

    /*global module, define */
    if (typeof module === 'object' && !isNull(module) && isTypeObject(module.exports)) {
        module.exports = defineAstroDate(addBigNumberModule.call({}));
    } else if (typeof define === 'function' && isTypeObject(define.amd)) {
        // "name" should be removed when finished with local testing
        define('astrodate', function () {
            return defineAstroDate(addBigNumberModule.call({}));
        });
    } else {
        globalThis.AstroDate = defineAstroDate(addBigNumberModule.call({}));
    }

of course the downside to this is that I have to rebuild my project if I wish to include a newer version of bignumber.js, and I have to do my linting before including it. But it's a solution that is working for me.

from bignumber.js.

+1 for this one.

It would be great if we can have different, independent BigNumber instances or factories with their own custom configuration instead of having global configuration. Right now, as soon as you have a project where multiple modules use BigNumber.js under the hood requiring different settings, you have a problem...

from bignumber.js.

Yes, I've been considering whether to add the BigNumberFactory code above when I push the non-integer powers update in a week or two. As it seems to have some support I probably will do so.

from bignumber.js.

Thanks, that would be great.

I think in general only static modules/functionality should be available globally. Non-static modules with configuration should be instantiated to prevent the possibility of conflicts.

Usage could also look something like this (always work via a factory):

var BigNumberFactory = require('bignumber.js');

// create a factory with configuration
var factory1 = new BigNumberFactory({DECIMAL_PLACES: 3});

// create a factory and change configuration later on
var factory2 = new BigNumberFactory();                    
factory2.config(6);

// create a bignumber using a factory function
console.log(factory1.bignumber(1).div(3).valueOf());  // 0.333
console.log(factory2.bignumber(1).div(3).valueOf());  // 0.333333

from bignumber.js.

I take your point, but considering backwards compatibility and simplicity of use, the BigNumber object will probably remain as it is but with a static new or copy method added.

var BigNumber = require('bignumber.js');

var SmallNumber = BigNumber.new();
SmallNumber.config({ DECIMAL_PLACES: 50 });

var x = new SmallNumber('1e-30').div(3);

from bignumber.js.

lol, I like your example ;)

from bignumber.js.

As a thought, and you were asking for ideas for the name, rather than new (which probably is a bad one, as IDEs will complain about reserved keywords), or ànew or copy (which could cause confusion), how about factory?

from bignumber.js.

@Xotic750

I have just published decimal.js which includes a noConflict method and also allows muliple Decimal constructors to be efficiently created, each with their own independent configuration.

I ended up using the name constructor not factory as I wanted to overwrite the existing constructor property from the prototype.

from bignumber.js.

Thanks, I will giving it a whirl.

from bignumber.js.

Like what you have done there, however, for my application I need precision to work with decimal places and not significant figures. Have you had any further thoughts of adding a factory method to BigNumber?

from bignumber.js.

I added it to big.js not long ago, so perhaps you could use that if you want to work with decimal places.

To create a fresh constructor in decimal.js:

D = Decimal.constructor();

And in big.js:

B = Big();

In bignumber.js? Not sure...

I'll consider it further, but I updated bignumber.js just recently, so I'd prefer not to look at that code again for a few months...

from bignumber.js.

I'll have a closer look at Big and see if that handles everything I need.

from bignumber.js.

So, there is no .config in big.js other than editing the file itself, and no support for NaN and Infinity? Doesn't seem to fit my bill unfortunately.

from bignumber.js.

No NaN and Infinity, but decimal places and rounding mode can be set using, for example

Big.DP = 20;
BIg.RM = 1;

from bignumber.js.

Aha, thanks for the config info. Don't think I can do without the NaN etc support though.

from bignumber.js.