[mdt-ocl.dev] Introducing Long support

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

Trying to rescue the bug/344368 we have the additional constraint that 
we are now past M6 the API freeze, which isn't entirely bad for 
maintaining long term legacy API compatibility anyway.

To summarize:

Internally the Ecore engine mostly uses Long, but:

We need to enhance IntegerLiteralExp and IntegerLiteralExpCS to support 
Long as well as Integer.

The proposed introduction of LongLiteralExp is not acceptable to me or 
API tooling, since QVTo and Acceleo may need to consider what to do 
about e.g. visitLongLiteralExp.

The proposed dual integerSymbol/longSymbol is not acceptable to me 
because an XMI serialisation may be incompatible.

I suggest adding a default-zero extendedIntegerSymbol field to both 
IntegerLiteralExp and IntegerLiteralExpCS such that the longSymbol is 
derived as extendedIntegerSymbol<<32 + integerSymbol. The 
extendedIntegerSymbol will therefore be zero and not serialised for all 
existing usage.

New code may invoke getLongSymbol() or setLongSymbol(). Old code is 
unaffected and will be protected by a new ParserOption that must be 
explicitly set to enable greater than 32 bit number parsing. We now have 
a preference page in which users could control this and so almost 
certainly enable 64 bit support in QVTo without QVTo changing at all.

Since this is in a grey area API-freeze-wise, is everyone happy to go 
for this in M7? Any -1 and it doesn't happen, probably ever.

    Regards

        Ed Willink