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

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

> > 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.
>
>  the OCL spec (I sucked my breath in a read it - well actually just scanned
> for the word "integer" :-)) does not, indeed, specify the range - it does
> have an intriguing mention of an UnlimitedInteger type - it gets mentioned
> just once in Chapter 11 (assuming you are using OCL 2).

No comment ;-).



> > 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
> > ;-).
>
> I'll guarantee it is slower :-) but long could be a more accommodating
> primitive as a default -

True.


> > 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?
>
> I like the optional plugin of the "Big..s" - then you are aware the you're
> paying some performance cost for the bigger capacity. It would be necessary
> to support the possible changes in the EMF handler to convert the Bigs

Yes. If we improve the conversion code, we may not need to have a
specific patch for "Big...s".

Would you have time to work on a patch with these features?


Frédéric