nits on BigInt Proposal

[J Decker]

On Fri, Aug 4, 2017 at 10:16 AM, Sebastian Malton <sebastian at malton.name>
wrote:

> 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.


Sebastian
>
> *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
>>> type.
>>>
>>> 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
>> structure.
>>
>> 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
>> need to be in every javascript implementation.
>>
>> 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
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170804/fa13fd98/attachment.html>