4 ms·
You do what all those examples you just listed do, you say int is 32-bit which fits in JavaScript number just fine. Then for longs you either don't support the
by kllrnohj 9y ago
You do what all those examples you just listed do, you say int is 32-bit which fits in JavaScript number just fine.
Then for longs you either don't support them or suck it up and pay the manual cost, which is what kotlin.js does.
Only dart did this crazy nonsense of an int type that is 2^53 sometimes and has methods like isNaN() on it.
- munificent 9y ago> you say int is 32-bit which fits in JavaScript number just fine. 32 bits isn't actually enough for many uses today. Lists with more than 2^32 elements are not unheard of. File offsets larger than that are certainly a thing. Dart only has a single integer type, so restricting it to 32 bits would restrict all users of integers to that size. > Only dart did this crazy nonsense of an int type that is 2^53 sometimes and has methods like isNaN() on it. isNan() is a method on num, which is the supertype of int and double, where it makes sense. (I don't know why they didn't define it just on double.)
- kllrnohj 9y ago> Lists with more than 2^32 elements are not unheard of. In the use cases Dart targets yes, yes they are. They are extremely unheard of. BUT even if they aren't, you can't use those from dart2js anyway. JS arrays are limited to uint32 lengths: "Every Array object has a length property whose value is always a nonnegative integer less than 2^32" https://www.ecma-international.org/ecma-262/5.1/#sec-15.4 https://www.ecma-international.org/ecma-262/5.1/#sec-15.4 Now sure you could make your own list type that lets you index to 2^53 in Dart, but you're into custom list territory now and math operations on a 64-bit long being a bit slower than native is unlikely to be relevant. You're probably not using flat indexing at that point anyway. File offsets actually highlights the perfect problem with dart's approach. 2^53 isn't enough to interop with file systems using uint64s, as node.js discovered when trying to use JS Number for inodes ( https://github.com/nodejs/node/issues/12115 https://github.com/nodejs/node/issues/12115 ) So things that actually need large numbers don't work anyway.
- dragonwriter 9y ago> In the use cases Dart targets yes, yes they are. They are extremely unheard of. Dart is a general purpose language it wasn't intended to be web front-end only. > File offsets actually highlights the perfect problem with dart's approach. 2^53 isn't enough to interop with file systems using uint64 Dart ints aren't limited to 2^53 except when using dart2js. It's an arbitrary size type, otherwise. Anyplace it would need to deal with inodes, the dart2js limit wouldn't be a problem.
- dragonwriter 9y ago> isNan() is a method on num, which is the supertype of int and double, where it makes sense. (I don't know why they didn't define it just on double.) Because it allows more general code to apply isNaN to nums generally, and always be false for ints (or potential future subtypes that likewise can't be NaN), even leaving aside JavaScript environment questions.
- kllrnohj 9y agoBut dart supports static typing, so that's just awkward. What does it even mean to take a num? What do you do with a generic num that may or may not be a double where isNaN makes sense? What value does this even have in a world of only int & double anyway? If a function returns 'num' does that mean isNaN is now something I need to worry about, or is it just badly over-generic code and it meant 'int'? Stepping back, though, methods like isNaN only apply to a specialized subset of numbers, not the base on which all numbers build off of. So putting it on the base number class is the wrong layering. Same reason that bitwise operators are on int instead of num, because they don't apply to all numbers.