Typescript: using BigInt instead of number

[randomnamehmm]

Would it be possible to change the type "BigInt" for integer numbers instead of using the type "number" when generating typescript code from an Ecore metamodel?

[schwichti]

I do not fully understand your request. Currently, the Ecore data type BigInt is mapped to TypeScript's type number. TypeScript/JavaScript do not have an integer type. Nevertheless, the BigInt to number mapping is a temporary hack anyway. I have checked it just now and it appears that TypeScript is supporting BigInt: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-2.html#bigint in the meanwhile. Someone would need to change it in CrossEcore codegenerator: https://github.com/crossecore/crossecore-generator/blob/master/src/com/crossecore/typescript/TypeScriptTypeTranslator2.xtend#L111 and here https://github.com/crossecore/crossecore-generator/blob/master/src/com/crossecore/typescript/TypeScriptTypeTranslator2.xtend#L334.

I don't know if this answers your question. Let me know.

[randomnamehmm]

Sorry that I wasn't clear enough. I meant that when you have the type EInt, EShort or ELong in your Ecore metamodel, the CrossEcore Generator should generate a TypeScript BigInt variable for it. Otherwise certain rounding issues appear due to Javascript's "number" type using a floating point represenation.

[schwichti]

In the original EMF project, ecore:EInt, ecore:EShort and ecore:ELong are mapped to java:int, java:short and java:long. I take this as reference. The range of javascript:number where you can safely store integers in is [-(2^53-1), 2^53-1] (see https://2ality.com/2013/10/safe-integers.html). This means java:int and java:short completely fit into javascript:number. Java:long does not fit completely into javascript:number. Is that what you mean with rounding issues? At first sight, mapping ecore:ELong to javascript:bigint makes sense to me. However, I see no need to change the mapping from ecore:EInt/ecore:EShort to javascript:number.

[schwichti]

"As specified in ECMAScript, mixing numbers and bigints in arithmetic operations is an error. " is an argument to map every type to bigint.

[randomnamehmm]

Yes exactly, I meant the rounding issues in ELong.

[schwichti]

What was your reason to suggest mapping short and int to bigint? Do you have, for example, the use case to mix different types in arithmetic expressions?

[randomnamehmm]

I was unsure whether or not Short and Int could produce similar rounding effects as with Long. That's why my suggestion was to not use a floating point number system for these types. If this is not an issue, I think only mapping ELong to BigInt would be sufficient.

[schwichti]

Here are some of my considerations. Besides BigInt, I also take BigDecimal into account, which is related.

• It seems that you cannot polyfill native BigInt for older browsers (see https://github.com/GoogleChromeLabs/jsbi#why)
• There is a BigDecimal proposal for ECMAScript (see https://github.com/tc39/proposal-decimal)
• There are libraries for BigDecimal and BigInt, e.g. big.js

There are four solution approaches:

• Make the CrossEcore generator configurable and let the CrossEcore user decide if to use native BigInt or big.js as a fallback. Pro: Flexibel Contra: Implementation overhead
• CrossEcore generator emits JSBI code and let the user transpile JSBI code to native BigInt if needed. Pro: Flexibel Contra: Does not work for BigDecimal (yet)
• CrossEcore generator emits big.js code and will ignore native BigInt and BigDecimal now and in future releases. End of story. Pro: Will work by now Contra: dependency to big.js.
• CrossEcore generator emits its own BigInt and BigDecimal wrapper classes that are to be included in the CrossEcore runtime. For an initial release, it would be a wrapper for big.js and for later releases maybe native BigInt/BigDecimal. This also allows to implement BigInt and BigDecimal consistently (i.e. with the same API) across all supported platforms. Pro: Flexibel Contra: little performance overhead

Let me know your preference.