Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [henshin-dev] Type parameters

Hi again,

ok, now I have got a challenge for you: say we want to be able to copy arbitrary EMF models with Henshin (as provided by the EcoreUtil.copy() method). Since we currently support only statically typed rules, this is not possible. So we need a concept of type variables, e.g. we match an object together with its type, say x:X, and we want to create a new object x':X. The thing is that we don't know X beforehand. It would be really great if we could extend Henshin to support such use cases.

Cheers,
Christian

On 11/17/2012 3:34 PM, Christian Krause wrote:
Hi,

I am thinking now that the use of type parameters would be too limited. The thing is that the user still needs to set the concrete types at runtime. This, he/she could also easily do now already by programmatically changing the types of nodes, edges or attributes (as I wrote in an earlier e-mail). I think type parameters would be only really useful together with a notion of inheritance. But rule inheritance is a tricky concept and I think we should avoid going into that direction.

Cheers,
Christian

Am 11/15/2012 9:22 AM, schrieb Christian Krause:
Hi Felix,

meta-programming, i.e., higher-order transformations, are supported by Henshin already. I agree with you that we should support the users for defining HOTs more easily, but I do not have an answer how to achieve this.

What I suggested is less powerful and has a different purpose. Type parameters can be directly compared with generics in Java or type parameters as supported in Ecore. The idea is to be able to define a "rule schema" which can be instantiated for different concrete types.

Regarding the changes to the model: we would need only the additional containment reference in Unit. If no type parameters are used, this reference stays empty and everything works as before.

I am also not sure whether this is the right way to go. Let's discuss this a bit more.

Cheers,
Christian

On 11/14/2012 03:56 PM, Riegerf@xxxxxxxxxxxxxxxxxxxxxxx wrote:
Hi,

Quoting Christian Krause <henshin.ck@xxxxxxxxx>:
Here is a possible way to integrate it in Henshin. We add a new 0..n containment feature called "typeParameters" to the Unit class.

I think model changes have to be really worth it, as the cost of changing the model is rather high. Therefore, I tend to oppose changing the model for (these) specific features. Keeping the model small allows us to support all its features in every component of the henshin project.

The type of this reference would be EModelElement. It could be used e.g. to store EClasses, EReferences or EAttributes. These types are contained in the unit / rule and can be used as types of nodes, edges, attributes or parameters. In the runtime, we would add support for setting type parameter values in UnitApplication.

At the moment, I do not see the huge benefits of having direct support for these features in the model. They would only complicate our core model, which is already very large.

So if we defined e.g. a type parameter "Class" for our refactoring, we could say in the rule application that this type parameter should be substituted with the type "EClass" from the Ecore metamodel (or "Class" from the UML metamodel).

We should think about ways to accomplish this by using our current model and tools. One thing that comes to my mind is using a graph transformation language to specify this transformation on the Rule--i.e., henshin itself. This is a nice application for meta-transformations, which I do believe we should support much more easily in henshin; many problems can actually be solved through metaprogramming. Of course, the usual restrictions w.r.t. metaprogramming apply, i.e. performance (I don't see us replacing already implemented core functionality by meta-transformations in the near future, so this shouldn't be too much of an issue) and usability (meta-transformations can be confusing to specify). However, the benefits, e.g. being able to express more without having to change the Java codebase, outweigh the problems. Since we do not rely on meta-transformations for our current (and very expressive!) transformation model, I also do not see any point in not making it meta-circular, irrespective of the problems that are associated with this.


Felix

_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev





Back to the top