Description Christian Damus 2009-06-23 15:17:12 EDT

Created attachment 139905 [details]
Fixes for datatype limitations

There are a number of problems in the EMF typesystem implementation that make it impossible to work with the values of EDataTypes in the Xtend language.  In particular, for EDataTypes that are not defined by Ecore (and therefore not statically mapped to Xtend's core type system):

  - values of an EDataType are always determined at runtime
    to be of type Object, so looking up features and operations
    that have the data type in their signature fails.  For example,
    invocation of a setPath(Path) operation always fails for my
    EDataType "Path" with an error message "Cannot find the operation
    setPath(Object) for ..."

  - exactly the same happens for the values of EEnums

  - similarly, run-time determination of the type of an operation
    argument that is an EList based on some data type fails because
    conversion of the value expects the list element type to be EList.
    For example, invocation of a setPaths(EList<Path>) operation
    (mutator for a "paths : Path [*]" feature) fails because the
    EmfListType::convert(...) method expects EList<EList>

In order to work around these problems, I have to create Java extensions to encapsulate everything I do with data type values.

I have attached a patch that makes data types work for me in my workflow.  Note that I am not attempting to implement support for data-type constructors as this would require changes to the Xtend expression grammar; I am relying on Java extensions for creation of new data-type values.  I am interested in maybe contributing such an enhancement in the future.

If you need a small-ish test case that manifests these problems, please comment and I will see what I can cook up.