Re: [m2m-atl-dev] XSD->ECORE->ATL - type conversion failures

["Frédéric Jouault" <frederic.jouault@xxxxxxxxxxxxxx>]

Hi,

> I agree with your remarks - the base typing (that referenced in the
> language and the engine) should remain compliant with OCL and any
> handler-specific conversions should be part of the handler - whcih is
> exactly where the "if (obj instanceof BigInteger)" code is missing amongst
> checks for other types when converting a model feature to an ASM... object
> - extending the handlers type conversions by a nice clean interface would
> certainly still be of benefit.

I agree :-).


> For the engine (and confessing to a less than perfect knowledge of the OCL
> spec) what is that spec's definition of an Integer's range? That should be
> the deciding factor of the default implementation, and, yes, if that
> doesn't suffice for certain applications then a "replacement mapping"
> technique would be useful.

Well, as far as I know, there is nothing in the spec about this.
Actually, I felt using BigInteger would be less efficient, but I must
admit I did not profile this.

If you can show me that using BigInteger is not slower than using
Integer, then I do not find any argument against not using BigInteger
;-).

But then, what about BigDecimal for Real? This "feels" more likely to
be slower, although this probably depends on the number of digits
after the point you keep. Then, the type replacing issue comes back:
what about having a default implementation with double, but offering
the possibility to plug BigDecimal instead, for specific purposes?


Frédéric