|Re: Implementation of UML::Integer too restricting [message #1049938 is a reply to message #1049747]
||Fri, 26 April 2013 13:27
| Ed Willink
Registered: July 2009
UML is not broken, so I don't see why OMG should change, and I can
predict very abrupt rejection of this change.
It seems that MDT/UML2's LiteralInteger is too close to Ecore.
If you use an OCL-languaged OpaqueExpression, the classic MDT/OCL you
will now get Long. The newer Pivot based MDT/OCL uses a Number that may
be BigInteger/Long/Integer/Short/Byte externally or IntIntegerValue,
LongIntegerValue or BigIntegerValue internally, the latter growing to
avoid ill-defined overflows and so getting much closer to an emulation
of the specified unbounded integers without imposing BigInteger on the
99.99% of more modest usages. Similarly for Reals.
It is hoped to have auto-generation of the UML 2.5 OCL constraints
direct from the OMG models for Luna, at which point this problem may
vanish. It is unlikely that anything will change before then because of
If UML 2.5 requires a major MDT/UML2 version change then it may be
possible to adjust the LiiteralInteger API slightly.
So worth a Bugzilla, but don't expect a fast response.
On 26/04/2013 09:11, Marc-Florian Wendland wrote:
> Hi all,
> I have found an interesting behavior when trying to set an value to an
> LiteralInteger. I used a integer beyond my platform-specific Integer
> range. As a result, the value was not changed. As a result, I cannot
> create a model with integer vaues that exceeds my machine capacity.
> This is somehow annoying, isn't it?
> I see two possible solutions:
> 1. Submit an official change request to OMG to change the value type
> of LiteralInteger to String (least favorable solution).
> 2. Change the UML2 implementation of Integer from int to BigInt. I
> would opt for this.
> Does this make sense? Shall I file a bug?
Powered by FUDForum
. Page generated in 0.01943 seconds