On Fri, Aug 4, 2017 at 10:16 AM, Sebastian Malton <[email protected]> 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:* [email protected] > *Sent:* August 4, 2017 12:20 PM > *To:* [email protected] > *Subject:* Re: nits on BigInt Proposal > > > > On Fri, Aug 4, 2017 at 9:10 AM, J Decker <[email protected]> wrote: > >> >> >> On Fri, Aug 4, 2017 at 7:52 AM, kai zhu <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
