Localize all vars

[Rudxain]

Prevents external code from changing the behavior of the library by modifying property values of global objects that some functions depend on. This means using aliases to objects, and copying primitive values

[fitiskin]

Just an idea. Perhaps it would be more convenient to organize the library as a npm package? So that all functions would be available without monkey patching, touching globalThis object and expanding native prototypes such as Number or BigInt.

import { Numeric, Float } from 'well-named-enhanced-js-math-library'

or even

import { modPow } from 'well-named-enhanced-js-math-library/math'

It will allow users to safely use the code in their projects without fear of breaking them with a new suddenly adopted ECMAscript standard.

I would help you with package building, refactoring, and so on.

What do you think?

[Rudxain]

@fitiskin I've been considering doing that. This library includes a lot of stuff that would probably never be added to the official ES spec (like Fibonacci, and inverse factorials), so it shouldn't be used as a polyfill, but rather as a standalone library. Another solution is to remove anything/everything that is not strictly and definitely included in a Stage [1, 4] proposal, ensuring there's more safety about using this as a polyfill. All of the removed functions can then be migrated to my "Useless-Math" repo, and then I would turn that into a non-polyfill standalone library distributed using NPM.

Also, IIFE polyfills ensure everything behaves exactly like built-in methods, so using ESM may not be a good idea for this. I need more info to take a better decision about it.

The problem with my "solution" to remove stuff is that the library would become useless very fast, because core-js already has better polyfills for future JS math, but I want this library to add more stuff because it makes it more unique.

Maybe I should completely abandon the polyfill library concept, and just turn this into a normal library. I could still make polyfills for future stuff, but in smaller quantities, which would make it easier to maintain and change, and I could post them as Gists instead of dedicating entire repos to them.

Thank you for your insight, I'll start thinking more about this

[Rudxain]

I realized this library wouldn't be useless even after removing everything that is not a Stage +1 proposal. I still haven't made the decision about the future of this library. I'll open a new Issue about this

[Rudxain]

For consistency, I decided that the only global values and fns that should be encapsulated/localized, should be everything but prototype methods, because of the call problem (infinite regress), and because using call makes the code less "elegant". So this library will do the assumption that all prototypes are immutable (even if they aren't)

[Rudxain]

I've given up on JS, so I'll 🦀RIIR in the future.

I'll keep the JS commit history in a secondary branch, for archiving purposes