7 ms·

Kind of bummed this is a new primitive type. Every instance of `typeof a === 'number'` just became `typeof a === `number` || typeof a === 'bigint'`... EDIT: Th

Kind of bummed this is a new primitive type. Every instance of `typeof a === 'number'` just became `typeof a === `number` || typeof a === 'bigint'`... EDIT: The more I think about it (and the more comments I get), the more I think this might actually be a good thing. I think bigint will probably not be used in places where integer numbers are currently used, and it might be unreasonable to expect code to work with numbers or bigints. In that case, it's actually probably good that you can easily tell the difference using typeof, without requiring some hacky fix like `Array.isArray`. It does mean that "don't mix numbers and bigints" is going to become very popular JS advice soon.

1f60c 7y ago
What makes you think that, exactly?
metalliqaz 7y ago
It seems to me that in applications where there is widespread use bigint, you would simply be doing `typeof a === 'bigint'`. And, in nearly all other applications, it would remain as simply `typeof a === 'number'`
- sbr464 7y ago
  That’s what we did for our financial and technical (science/math) backend services that use node.js. We just don’t use the built-in number/float libraries, instead using an abstraction library based on bignumber.js/decimal.js etc, consistently.
jchw 7y ago
To be fair, it really shouldn’t be conflated with ‘number’ - it isn’t the same thing, the behavior differs. And you can (and probably should) use small helper functions for these kinds of checks, pretty much for this kind of flexibility. Kind of curious what other libs (like lodash) will do.
- wvenable 7y ago
  If you're really going to do it right, that small function should also be published as npm package (isnumeric) that takes at least 2 other packages (isnumber and isbigint) as dependencies.
  - jchw 7y ago
    I’m super strongly against this concept actually, which you might gather from mention of lodash.
    - coolreader18 7y ago
      I think they were making a joke.
      - jchw 7y ago
        Obviously it was some degree of tongue-in-cheek, but I’m not really that amused, to be honest. It needs a leftpad reference or something.
        jchw 7y ago
        I see I’ve struck a nerve of some kind so I’d just like to clarify that I am not sorry.
        fgonzag 7y ago
        Anybody who thinks that's actually good (or even real) advice is going to write horrible code regardless, IMHO.
        wvenable 7y ago
        https://www.npmjs.com/browse/depended/is-number https://www.npmjs.com/browse/depended/is-number
        7y ago
hombre_fatal 7y ago
By that logic, you should also test if `a` is a string that can be parsed into a number/bigint as well. Or if it's a Uint8Array that you can decode into a number/bigint. But that's not how you write software. In an application, you have a canonical representation that you pass through your business logic.
- dlbucci 7y ago
  I don't know if that follows. I think it's reasonable to expect a piece of code that works with integer numbers to also work with bigints. But it's not really reasonable to expect it to work with anything that closely resembles a number. That sort of weak typing is much more problematic and should be avoided. But I dunno, maybe it shouldn't be expected to work with bigints either. It's not a regular int, so I doubt people will start using these as array indices in for loops or what have you, so maybe it should be a different type...
  - hombre_fatal 7y ago
    But it's really not. Pretty major difference between floats and arbitrary precision, like how you'll get different arithmetic results passing in 42 vs 42n. Just like any language that doesn't let you mix float and integer operands. Also, what's even the return value? You need to make a deliberate decision about your data, not deck the halls with just-in-case programming. The software you write will be much better for it. Besides, even if you could justify a bunch of typeof checks and you were doing it everywhere, Javascript already has a way to spare you from repetitive code: a function.
  - recursive 7y ago
    Well, bigints are fine as array indices. However they are not interoperable with numbers in any type of arithmetic. I don't think it's reasonable to expect to use bigints in any place where one uses numbers. "Regular int" is not a distinct type in javascript. There are now two numeric types: 64-bit floating point, and bigint.
    - IggleSniggle 7y ago
opencl 7y ago
For code that actually needs bigints mixing numbers and bigints is just asking for horrible bugs like when a bunch of Twitter clients completely broke after 2^53 posts had been made.
chungleong 7y ago
The more I think about about it the less I like this new feature. They should have implemented BigInt as a class instead and rely on a transcoder to make algorithms easier to write.
AgentME 7y ago
You can't do arithmetic with numbers and bigints, so when would you ever accept a parameter that could either be a number or a bigint? The places that `typeof a === `number` || typeof a === 'bigint'` could be used seem rare to me.
neilv 7y ago
It may be a good thing, for historical/backward-compatibility reasons. But there's no reason that fixed-size ints and IEEE floats can't be intermixed with arbitrary-size/precision numbers, even in a small language, such as Scheme: https://schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html#%_sec_6.2 https://schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-... Racket adds a bit more: https://docs.racket-lang.org/reference/numbers.html https://docs.racket-lang.org/reference/numbers.html IIRC, Brendan Eich was aware of Scheme when he defined what's now known as JavaScript, but on a crazy-tight schedule, and JS wasn't intended to be an applications language.

1f60c 7y ago

What makes you think that, exactly?

metalliqaz 7y ago

It seems to me that in applications where there is widespread use bigint, you would simply be doing `typeof a === 'bigint'`. And, in nearly all other applications, it would remain as simply `typeof a === 'number'`

sbr464 7y ago
That’s what we did for our financial and technical (science/math) backend services that use node.js. We just don’t use the built-in number/float libraries, instead using an abstraction library based on bignumber.js/decimal.js etc, consistently.

jchw 7y ago

To be fair, it really shouldn’t be conflated with ‘number’ - it isn’t the same thing, the behavior differs. And you can (and probably should) use small helper functions for these kinds of checks, pretty much for this kind of flexibility. Kind of curious what other libs (like lodash) will do.

wvenable 7y ago
If you're really going to do it right, that small function should also be published as npm package (isnumeric) that takes at least 2 other packages (isnumber and isbigint) as dependencies.
- jchw 7y ago
  I’m super strongly against this concept actually, which you might gather from mention of lodash.
  - coolreader18 7y ago
    I think they were making a joke.
    - jchw 7y ago
      Obviously it was some degree of tongue-in-cheek, but I’m not really that amused, to be honest. It needs a leftpad reference or something.
      - jchw 7y ago
        I see I’ve struck a nerve of some kind so I’d just like to clarify that I am not sorry.
      - fgonzag 7y ago
        Anybody who thinks that's actually good (or even real) advice is going to write horrible code regardless, IMHO.
        wvenable 7y ago
        https://www.npmjs.com/browse/depended/is-number https://www.npmjs.com/browse/depended/is-number
        7y ago

hombre_fatal 7y ago

By that logic, you should also test if `a` is a string that can be parsed into a number/bigint as well. Or if it's a Uint8Array that you can decode into a number/bigint. But that's not how you write software. In an application, you have a canonical representation that you pass through your business logic.

dlbucci 7y ago
I don't know if that follows. I think it's reasonable to expect a piece of code that works with integer numbers to also work with bigints. But it's not really reasonable to expect it to work with anything that closely resembles a number. That sort of weak typing is much more problematic and should be avoided. But I dunno, maybe it shouldn't be expected to work with bigints either. It's not a regular int, so I doubt people will start using these as array indices in for loops or what have you, so maybe it should be a different type...
- hombre_fatal 7y ago
  But it's really not. Pretty major difference between floats and arbitrary precision, like how you'll get different arithmetic results passing in 42 vs 42n. Just like any language that doesn't let you mix float and integer operands. Also, what's even the return value? You need to make a deliberate decision about your data, not deck the halls with just-in-case programming. The software you write will be much better for it. Besides, even if you could justify a bunch of typeof checks and you were doing it everywhere, Javascript already has a way to spare you from repetitive code: a function.
- recursive 7y ago
  Well, bigints are fine as array indices. However they are not interoperable with numbers in any type of arithmetic. I don't think it's reasonable to expect to use bigints in any place where one uses numbers. "Regular int" is not a distinct type in javascript. There are now two numeric types: 64-bit floating point, and bigint.
  - IggleSniggle 7y ago

opencl 7y ago

For code that actually needs bigints mixing numbers and bigints is just asking for horrible bugs like when a bunch of Twitter clients completely broke after 2^53 posts had been made.

chungleong 7y ago

The more I think about about it the less I like this new feature. They should have implemented BigInt as a class instead and rely on a transcoder to make algorithms easier to write.

AgentME 7y ago

You can't do arithmetic with numbers and bigints, so when would you ever accept a parameter that could either be a number or a bigint? The places that `typeof a === `number` || typeof a === 'bigint'` could be used seem rare to me.

neilv 7y ago

It may be a good thing, for historical/backward-compatibility reasons. But there's no reason that fixed-size ints and IEEE floats can't be intermixed with arbitrary-size/precision numbers, even in a small language, such as Scheme: https://schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html#%_sec_6.2 https://schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-... Racket adds a bit more: https://docs.racket-lang.org/reference/numbers.html https://docs.racket-lang.org/reference/numbers.html IIRC, Brendan Eich was aware of Scheme when he defined what's now known as JavaScript, but on a crazy-tight schedule, and JS wasn't intended to be an applications language.