Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] Introducing Long support


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.


        Ed Willink

Back to the top