Alternative to Number.prototype syntax

[drewpointone]

• Related to the thread in Prototype extension of Number leads to incompatibilities with TresJS #58

Maybe I can offer a global flag that can be set to disable patching? Along with exposing a functional API.

If a functional/alternative API doesn't have significant performance downsides, I think that should just be the primary use pattern.

Or, if not, maybe we can consider use some sort of namespacing/prefixing approach.

[krispya]

Hello! This is by far the most controversial decision I made with the library. So, to be clear, functional patterns are almost always just as performant or more performant than any API that uses objects. What the patching of Number.prototype does is get the performance of using number primitives with an object-like API. It's an almost win-win decision until you consider it is unusual to patch this prototype (though not at all against how the language is meant to be used). Because it is unusual, frameworks will not assume it and you get the issues like the on you linked.

My argument has been that these frameworks can harden their method checks in the first place, but I get that I am walking on thin ice here. I don't want to prefix the methods, but I think it would fine to have an export that does not do this since the internals are all functional anyways. Maybe something like this:

import { addTrait, setTrait, removeTrait } from 'koota/functional'