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

[Martin J Bartlett <jbartle9@xxxxxxx>]

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.

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.

Thanks

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




                                                                       
             "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 00:07          type conversion failures        
                                                                       
                                                                       
             Please respond to                                         
             M2M ATL Developer                                         
                   list                                                
             <m2m-atl-dev@ecli                                         
                 pse.org>                                              
                                                                       
                                                                       




Hi Martin and Dennis,

> A similar issue has come up before, regarding mixed content in XSD-based
> meta-models. It is documented in Bug # 156094:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=156094
>
> The asm2EMF() and emf2ASM() methods have been modified to support the
> EMF FeatureMap.Entry objects. The ASMTuple type has been used to
> represent this EMF object in "ASM-land".

Dennis is right: model handler specific type conversion should be
performed in the corresponding driver (i.e., class ASMEMFModelElement
of emf4atl for EMF).

Note that it is always possible to define a new driver for specific
cases that do not fit the general case, as we did for UML2. However,
this is probably not be necessary to handle XSD types.


> As for extensibility: I was under the impression that Ecore supports a
> fixed set of primitive types as does ATL's ASM format. The problem is
> that the mapping between both is apparently not complete.
>
> While you could probably do some conversion hacks for BigInteger and
> BigDecimal, you'll likely run into problems later. I think the native
> ASM library needs two extra ASMNumber subclasses to properly represent
> these types. The fact the Ecore does not have an infinite amount of
> primitive types makes this exercise worthwhile. What do you guys think?

ATL types are based on OCL types, not EMF types. However, this should
not be that big an issue, unless arbitrary Java types are used (i.e.,
by playing with instanceClassName, as I have seen it done a couple of
times)..


Currently, it is possible to add and/or replace operations. It would
be nice to be able to add and/or replace types.

Obviously, adding types should be reserved for specific purposes
(e.g., using the ATL VM for other languages), because it generally
requires language-level support as well.

However, replacing types may have some interesting uses. For instance,
although int should probably remain the default Java type mapping for
OCL Integer, it might be useful to have a BigInteger alternative.


Regards,

Frédéric
_______________________________________________
m2m-atl-dev mailing list
m2m-atl-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2m-atl-dev