[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [henshin-dev] Bugs and feature requests related to Edges in Henshin
|
Hi Gabi,
Am 3/7/2013 8:46 AM, schrieb Gabriele Taentzer:
Hello Christian,
you propose very interesting extensions of Henshin. I support all of
them and have another one described below. In the following, some
questions.
Am 06.03.2013 20:41, schrieb Christian Krause:
* Automatic handling of opposite edges. In the moment when you want
to delete an edge of a type which has an eOpposite reference, you
must either explicitly specify that the opposite edge is deleted too,
or you have to set the rule flag "checkDangling" to false. It should
be possible to specify only one edge and still have checkDangling
turned on. Probably it is the best to make the interpreter aware of
the special semantics of opposite edges.
That's certainly a good idea.
* Dangling condition for multi-rules. Currently, the dangling
condition is checked for every rule individually. If a kernel rule
deletes a node, and its multi-rules delete *all* dangling edges, then
the rule should be applicable with checkDanging=true. This is
currently not the case because the dangling condition is checked
separately for each rule.
Also good.
Another possible extension would be a possibility to specify the minimum
number of matches required for a multi-rule in order for the rule to be
applicable. For example, if I specify a minimum of 1, then it means that
the multi-rule must be matched at least once in order for the rule to
fire. A specific example are the Gossiping Girls:
http://www.eclipse.org/henshin/examples.php?example=gossipinggirls. With
a minimum of 1 multi-match, you would remove all self-loop transitions
(these are meaningless phone calls where no secrets are exchanged).
* Support for matching the index of an edge. The Edge class gets a
new attribute called "index" of type String. This can be used to
match the index of a link in a (many-) reference. The value of the
index attribute is interpreted using the JavaScript engine --
basically in the same way as attributes. For example, I can have a
rule with an Integer parameter "x" and match a node with two outgoing
edges of the same type, one with "x" and the other with "x+1" as
index. The rule could then create another edge with the index "x+1"
which will create the link between the other two links. Note that
setting indizes in this way may yield nondeterministic results, e.g.
when you set the indizes of two edges. Anyway, I strongly believe we
need such a functionality (e.g. for JaMoPP).
This is good to specify ordered sets as we need it e.g. for parameter
lists. Then, it would be possible to specify e.g. a switch of two
parameters. However, I do not understand this sentence: The rule could
then create another edge with the index "x+1" which will create the
link between the other two links.
Sorry, my example was a bit abstract. Let's say I have an EMF model of
some Java code where the code is stored as a list of statements (as in
JaMoPP). Let's say I want to add a new statement behind the statement at
the position x in the list. Then I could just specify to create an edge
at the index "x+1". Thereby the new statement will be added right after
the statement at position x. Note that x could be also inferred by the
engine, e.g. I could specify some properties of the statement at x
without explicitly saying what x is, e.g., I could say that it must be a
return statement. I could also match the last element in the list by
creating a NAC that says there exists no element with index y where y>x.
Another feature that would be helpful if not already there:
Collections (or sets) as input parameters: Defining an input parameter
of type Set<EObject> it can be used by multi-rules. Each element of
the set goes to a new copy of the multi-rule. Hence, there will be as
many copies as there are elements in the set.
Could you give an example? On a related subject, I think that we need a
new mechanism for synchronized rule applications (in addition to
amalgamation), e.g. for transitive closures.
Cheers,
Christian
Best wishes,
Gabi
