[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2m-atl-dev] XSD->ECORE->ATL - type conversion failures
|
Might have to wait a few weeks - but since I'm the requester I quess its
only fair :-)
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.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
"Frédéric
Jouault"
<frederic.jouault To
@univ-nantes.fr> "M2M ATL Developer list"
Sent by: <m2m-atl-dev@xxxxxxxxxxx>
m2m-atl-dev-bounc cc
es@xxxxxxxxxxx
Subject
Re: [m2m-atl-dev] XSD->ECORE->ATL -
26/10/2007 16:13 type conversion failures
Please respond to
M2M ATL Developer
list
<m2m-atl-dev@ecli
pse.org>
> > 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
_______________________________________________
m2m-atl-dev mailing list
m2m-atl-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2m-atl-dev
