| Re: [m2t-dev] [backend] bugs and thoughts |
Laurent,after looking at the Acceleo documentation, I would like to discuss a different approach to mapping ENode etc. to the backend with you.
It appears to me that ENode is not really a type but rather a set of infrastructure operations that can be applied to any object, i.e. a library. It looks like you could create an Acceleo specific library with functions operating on "Object".
What problems do you see with this approach? - Arno Laurent Goubet schrieb:
Arno, Comments below.Among those three possibilities you give, the third is the one that suits my needs. The example I took when first submitting this request is really close to my actual need, I'll elaborate on this from the beginning ;).I must admit I don't get your last suggestion quite well. As for the first, this seems promising, something like a "convert" method on the interface BackendType which would allow us to tell the backend how to effectively convert objects of a given type to (and from) ours would likely be enough for most conversion needs.I get the idea. I spent some time thinking this through. Before I explain my thoughts, could you give me a practical example of what you would want to use the feature for? Is that something that could be done by subtyping one of the built-in types?I see three potential ways to supplement BackendType:* add "convert from" functionality, i.e. allow a type to provide implicit conversions *to* it.* add "convert to" functionality, i.e. allow a type to provide implicit conversions *to* it.* add both of the above.Either of the first two is insufficient to implement full assignment compatibility of a newly created type with one of the built-in ones - the built-in type would not be modified, and one of the two directions of conversion would be barred.The third alternative introduces redundancy and therefore potential for inconsistencies.Which would you prefer? What are your thoughts?And anyway, would you care to point me to some material about your type system etc.? That would be helpful reading to understand and anticipate your future needs.There are strong consequences for implementation and performance, but I will elaborate on these when I have your response.The language I am testing the backend with is Acceleo (http://www.acceleo.org). This language appears to the user as weakly typed since everything is transparently converted to Acceleo-specific types : ENode for regular Objects (String, Integers, Long, ...) and ENodeList for Collections (ENodeList containing only ENodes). Let's take a look at a random Acceleo script :<%script type="EClass" name="getName"%> <%name%>What does this script mean? It defines a "method" /getName/ that can be called on objects of type "EClass". This could be translated in Java as a method (this also demonstrate the need we have for an expression "InvokeOnWhatever" that could seek for a class member instead of a method) :public String getName(EClass clazz) {final EStructuralFeature feature = clazz.eClass().getEStructuralFeature("name");return clazz.eGet(feature); }Please note that this is a totally dummy translation, I simply put it that way so that you can see a little better without knowing Acceleo. Regardless of the script's signification, what Acceleo sees "behind the scene" is not an EClass, but an ENode wrapped around an EClass. This allows for interesting use cases, but this isn't the issue here. When using this with the backend, I must have it know that a function defined with a parameter of type "ENodeType" (a backend type I have defined for the ENodes) *can be called *with parameters of type "LongType", "StringType", "EObjectType", ...For such use cases, both methods "convertTo(Object o)" and "convertFrom(Object o)" are mandatory for the backend (I have called my function, it returns an ENode, I need to convert it back to a primitive type).I don't know if this little example is enough for you to see the need behind that suggestion of type converters, maybe you could take a look at Acceleo when you have some time.Well I need IntegerTypes in order not to have to explicitely convert every int or Integer I get as parameters or return types for my methods to long. For the example I took, let's say I have to convert "if (1 + 1 == 2) { ... }" to the backend. I need to call the syslib's "operatorPlus" and "operatorEqual" functions. If I do "as is", I will wind up with the temporary expression "if (11 == 2)" since String concatenation will be called instead of operatorPlus on longs (with something like /InvokeOnWhateverExpression("operatorPlus", [1, 1], sourcePos)/) and the subsequent "operatorEqual" will return false.I wound up defining an IntegerType, the syslib's functions for it as well as modifying the LongType to allow assignment-compatibility from Integer on it so that I could test the backend further... this will obviously be a blocking issue for us, is there any plans from your side to create the missing primitives (int, float, char, ...)? I think this would also maker the JavaBuiltinConverterFactory obsolete.It was a conscious design decision to provide only Long and Double as numerical types. This was done in part to be compatible to OCL which (AFAIK ;-) ) has only these two types.I see no real problem with adding support for all Java types. But I am curious - could you explain the context for which you need these things?We then need to convert the parameters to long in order to have the expected result of "1 + 1". These syslib functions are not the only ones presenting the issue, I -let alone the users- use "int" parameters *way* more than I use long. I simply don't want to have these explicit conversions to handle each time I want to use primitive types (be it for a parameter or a return type). I explained in the previous mail that I ended up defining an IntegerType; I told it would be a blocking issue for us since this forces us to patch the backend in order to remove the JavaBuiltinConverter you use to convert int to long.Another option would of course be for you to use these builtin converters every time you see an integer, but I think this would be an issue for performances as well (these conversions are currently not carried on when searching for a function which could be called with given parameters in the PolymorphicResolver).Thanks for your efforts! - ArnoThanks for your reactivity Laurent Goubet Obeo
-- Arno Haase Langemarckstr. 16 53227 Bonn Mobil: +49 160 98525085 Tel: +49 228 9654443 Fax: +49 228 9654448
Attachment:
signature.asc
Description: OpenPGP digital signature