|
Hi Claudia,
thanks for the patch. There are a couple of things. First, as far
as I have seen the user constraints are not checked (should be
done in DomainSlot I guess). Also, I would prefer if the user
constraints would be "injected" in a simpler way.
What I would do is to leave RuleInfo and VariableInfo as they are
(but keeping the userConstraints list in Variable). The
UserConstraint should be an interface. If it does not add anything
to the Constraint interface, I would remove it and let the
userConstraints in Variable be of type List<Constraint>. But
if they should do something special, keep UserConstraint (as
interface). I would remove HenshinUserConstraint because it just
seems to provide a few helper methods for HenshinEGraphs.
To create the user constraints, I would add some code in
EngineImpl.getRuleInfo(). After creating the RuleInfo object, it
could invoke a protected method "createUserConstraints" in
EngineImpl. Per default this method has an empty body. If someone
wants to add user constraints he/she can simply extend EngineImpl
and override the createUserConstraints method. Do you think that
would be ok?
Cheers,
Christian
On 07/19/2012 01:05 PM, Claudia Ermel wrote:
Hallo Christian,
here is the patch updated to revision 1633.
Since package matching is now integrated into interpreter, all
changes have taken place in interpreter.
Thanks for considering the patch
(it might really be useful also for other Henshin users)
Best,
Claudia
-------- Original-Nachricht --------
Here is the Henshin Interpreter Diff with User Constraints
On 07/12/2012 04:40 PM, Claudia Ermel wrote:
Am 13.07.2012 13:43, schrieb Claudia Ermel:
> Hi Christian,
>
> thanks for the positive feedback.
> Your are right, it makes more sense to update our version to
the current revision first, including the patch. I will send you
the updated Java files when we have finished the update.
> But it's good to know that you agree in general.
>
> Best,
> Claudia
>
> Am 12.07.2012 20:34, schrieb Christian Krause:
>> Hi Claudia,
>>
>> your extension seems useful also for other applications
and I think it is a good idea to incorporate it into our
development version. Since we changed the API and the internal
structure of the interpreter (e.g. the matching plug-in was merged
into the interpreter plug-in), it would be more helpful if you can
send us the added or changed Java files. Then I can see what's the
best way to integrate them.
>>
>> Cheers,
>> Christian
>>
>> On 07/12/2012 04:40 PM, Claudia Ermel wrote:
>>> Dear Gregor and all,
>>>
>>> as discussed last Tuesday, we need a patch for
henshin.matching and henshin.interpreter that allows us in our new
triple graph grammar editor to apply rules according to certain
source consistency conditions.
>>> Using the patch, these conditions can be incorporated
in a special UserConstraint class where we implement the
additional checks that have to be performed for matching.
>>>
>>> In our particular case, we check a boolean attribute
"isTranslated" of a rule node that, if true, must be mapped to a
graph node only if this graph node has been translated before;
(and the other way round: a "false"-tagged rule node must be
matched only to a graph node that has NOT YET been translated --
we check this by looking up certain tables where we store ids of
translated elements).
>>> We cannot model this by an equally-bound
"isTranslated" attributes in the instance model because the
instance model (and its EMF model) must not be extended by new
attribute (types); the "isTranslated" attribute serves only for
rule application purposes, but does not belong to the model.
>>>
>>> Moreover, it does NOT help us to check only if the
objects are in the "used objects" list of the matchfinder, because
there may be objects that have been used by the rule before
("used_object=true") but should be used again by the next rule
since the matches of both rules may well overlap in these objects.
>>> The "used_object" value alone does not tell us
whether the "isTranslated"-values of rule and graph object do
coincide or not.
>>>
>>> Hence, we need the patch and would be very happy if
you could integrate it.
>>> The patch is very general and allows Henshin users to
add user-specific constraints to the matching process.
>>> (If no user constraints are needed, nothing has to be
done and everything works as before.)
>>> Here is a short description of the changes in this
patch (based on revision 1243):
>>>
>>> 1) in org.eclipse.emf.henshin.matching
>>> - new class in Package constraints: public abstract
class UserConstraint implements Constraint
>>>
>>> 2) in org.eclipse.emf.henshin.interpreter
>>> - new class: public abstract class
HenshinUserConstraint extends UserConstraint
>>>
>>> - in class EmfEngine:
>>> + a new variable
>>> private HashMap<Class<? extends
UserConstraint>, Object[]> userConstraints = new
HashMap<Class<? extends UserConstraint>,Object[]>();
>>>
>>> + a new method
>>> public void registerUserConstraint(Class<? extends
UserConstraint> con,Object... params)
>>>
>>> Using the patch in our particular case:
>>> Method registerUserConstraint is called in execute()
by us in tggeditor.commands.ExecuteRulesCommand:
>>> HashMap<Node, Boolean> isTranslatedNodeMap =
new HashMap<Node, Boolean>();
>>>
emfEngine.registerUserConstraint(RuleConstraint.class,
isTranslatedNodeMap);
>>>
>>> The RuleConstraint class is our TGGEditor class
tggeditor.commands.RuleConstraint and extends
HenshinUserConstraint and implements the source consistency check
we need.
>>>
>>> I attach the patches for matching and interpreter.
Please have a look and tell us what you think.
>>>
>>> Best,
>>> Claudia
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
|
