[
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
