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

[Martin J Bartlett <jbartle9@xxxxxxx>]

> 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).

> 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 -

> 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

Martin

CSC Financial Services SAS
Registered Office: 14 Place de la Coupole, Axe Liberté, 94220 Charenton Le
Pont, France
Registered in France: RCS Créteil B 323 127 332

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------