I've also never used them before and I don't know whether it will
work. The proper way to do it would be to encapsulate each subunit
in an Invocation object which carries the parameter assignments, I
think. But this would be a major change in the model.
On 01/14/2012 02:37 PM, Gregor Bonifer wrote:
Couldn't we solve this with a featuremap? I only read about
featuremaps and never actually used one. But as far as I
understand, we could create a transient/volatile reference that
aggregates two references and allows any ordering of the resulting
mixed collection. Such a map could merge Units and
ParameterMappings and would allow to define the order in which
they should be executed.
E.g.:
+ AnyUnit u
+-- Param X
|
+ SequentialUnit su
+-- Param Y
+-- Param Z
+-- PM Y -> X
+-- AnyUnit u
+-- PM Z -> X
+-- AnyUnit u
This would require that the execution of su would accumulate
parameter-values as defined by the mappings until it reaches a
subUnit which is then executed. After the execution the unit will
continue accumulating mappings until it reaches the next subUnit,
etc.
Using a common interface UnitStatement for ParameterMappings and
TransformationUnits seem problematic because of the containment of
ParameterMappings.
Perhaps we should clarify whether we are just looking for a
quickfix here or if this would be a good occasion for a critical
reexamination of the controlflow in general.
Regards,
Gregor
Am 14.01.2012 10:44, schrieb Enrico Biermann:
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
_______________________________________________
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
|