[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [henshin-dev] Type parameters
|
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
