I am not sure I see the problem. The parameter relation mapping
between a unit and one of its subunits should be injective. The
parameter relation mapping between a subunit and its unit (also
stored in the unit) should be injective. Any non-injective relation
will always have the problem of having to choose which value to
apply to a subunit (or the unit). Even if A->X, B->X wouldn't
be ambigous in the first place. Trying to put them in a proper order
like A->X first, then B->X second is futile at the moment.
Note that the injectivity apply only between the unit and exactly
one subunit. You can reuse unit parameters for different subunits as
well as set unit parameters with parameters from different subunits.
One possiblity would be
A -> X
B -> Y
And allow a syntax to map multiple parameters to a single field for
example:
attribute = {X|Y}
Another would be to use guards for parameter mappings i.e. allow a
specific mapping only if the condition is true. However I have no
idea what kind of information you would need here. Probably things
like state of parameters and information about previously executed
subunits.
I am not happy with either of these solutions and not sure whether
the injectivity restriction is that bad.
Regards,
Enrico
On 13.01.2012 23:20, Christian Krause wrote:
Assume you have a sequential unit with parameters A and B in which
another unit with a single parameter X is called twice. The first
time, it should be invoked with A, the second time with B. So I
have to add the following parameter mappings to the sequential
unit:
A -> X
B -> X
But now, when the subunits are invoked, the engine should get into
trouble because it does not know whether to pass A or B for X.
On 01/12/2012 12:53 PM, Stefan Jurack wrote:
Right, analogously to method calls where the caller passes parameters to
and fetches parameters from the callee.
Am 12.01.2012 12:26, schrieb Christian Krause:
Hi,
parameter mappings are managed by the parent transformation unit,
correct?
chhers,
christian
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
|