[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[mdt-ocl.dev] Introducing Long support
- From: Ed Willink <ed@xxxxxxxxxxxxx>
- Date: Tue, 01 May 2012 08:27:06 +0100
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
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.
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
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.