nits on BigInt Proposal
d3ck0r at gmail.com
Fri Aug 4 21:17:14 UTC 2017
On Fri, Aug 4, 2017 at 10:16 AM, Sebastian Malton <sebastian at malton.name>
> I remember that was a proposal for operator overloading. Was it decided
> against? I think that packages could solve this and many other problems if
> there was overloading.
I looked through outstanding proposals and didn't see any regarding
operator overloading. I'm personally not a fan of operator overloading,
although one can do clever things with abstract types like neurons and
neural meshes to use ( like building a merged input using N1 = N2+N3, it's
actually better to just use N1 = N2.Add( N3 ). which gives the ability to
add other parameters in the mix anyway) I'm not even a fan of C++ function
overloading, but rather, when porting backward from C++ to C, using well
named functions for appropriate inputs turned out to be much better for
clarity and maintenance.
With such vehement opposition to transparent things like extending JSON to
support a wider range of valid inputs; or even adding an additional
namespace for a separate version that does, I don't see how this has made
it so far, which adds an entirely new type that is sort of like Numbers,
but really nothing at all like Numbers.
> *From:* d3ck0r at gmail.com
> *Sent:* August 4, 2017 12:20 PM
> *To:* es-discuss at mozilla.org
> *Subject:* Re: nits on BigInt Proposal
> On Fri, Aug 4, 2017 at 9:10 AM, J Decker <d3ck0r at gmail.com> wrote:
>> On Fri, Aug 4, 2017 at 7:52 AM, kai zhu <kaizhu256 at gmail.com> wrote:
>>> looking at the use-cases for this feature @ https://github.com/tc39/prop
>>> osal-bigint#use-cases, i'm not convinced it improves everyday
>>> programming, or outweigh the benefit and simplicity having a single number
>>> my nits are:
>>> - will this break or complicate existing/future code that does typeof
>>> checks for numbers? what are the costs of retooling nodejs mongodb / mysql
>>> / etc drivers and the apps that use them?
>> from what I interpret, it's not a number; it's a different type entirely,
>> and does not interop with existing numbers
>>> - how will JSON.parse and JSON.stringify deal with BigInt? the mentioned
>>> use-cases for wire-protocols, guids, timestamps, and fixed-point BigDecimal
>>> aren’t very useful if it can’t easily be serialized / deserialized across
>>> db / persistent storage
>>> Apparently it will tostring and require a reviver.
>>> - are there actual common algorithmic use-cases in frontend programming
>>> or nodejs apps that need arithmetic on integers greater than 52-bits?
>>> should that rather be the domain of webassembly?
>> it's definitely NOT a webassembly thing, because it's a high level
>> It would simplify computing large factorials... instead of manually
>> chunking stuff to 5 decimal digits or 4 hex digits... not that it's much of
>> a use case...
>> But; there's already a library for this https://www.npmjs.com/package/
>> bigint. Why would this be something to add to the language any more
>> than extending JSON?
>> Regarding currency manipulation; I don't see that as something that is as
>> useful on the client side as it is on a server side... so it doesn't really
>> And, it seems more like a way to get around no operator overloading, by
> saying 'this specific case warrants it' but not vectors or complex numbers.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss