I am not convinced, that this is the best way. A SequentialUnit that
uses another Unit x times would need identical ParameterMappings x
times. This will occur when migrating a CountedUnit with a count of
x > 0. Derived visualizations might be able to deal with this in
an elegant way, but the effect on the tree-based editor is fatal.
As I illustrated earlier, it is possible to build a workaround with
the current model. So there is no actual need to change anything at
the moment.
However, I think it would be a good idea to think about the
controlflow definition in general. There are some more issues that
should get some attention. For example there is the problematic
aspect that a TransformationSystem becomes cluttered with
transformation fragments. Defining a complex transformation requires
to create units in the TS that have no meaning by themselves. Not
only is this affecting the readability but this also means that it
is not possible to keep up the notion of a TS as graph grammar, i.e.
there is no distinction between productions and production
fragments. If we address this issue (and I sincerely hope so) there
will probably be changes regarding the containment of units. This
would be a much better context for thinking about modelling
invocations in a mapping-friendly way.
Am 14.01.2012 16:52, schrieb Christian Krause:
How about this: for the execution, every ParameterMapping can be
used only once and the choice for a ParameterMapping is done based
on their order. I think that should work... (?)
On 01/14/2012 04:32 PM, Christian Krause wrote:
Sorry, I misunderstood your previous mail. the order does not
work, I see...
On 01/14/2012 02:48 PM, Christian Krause wrote:
Hi Enrico,
so the order of ParameterMappings determines which one is used
when? This is quite subtile and it must be specified exactly
what the semantics is. For example, assume the same setting as
before, so with the ParameterMappings
1) A -> X
2) B -> X
But now assume that the subUnit is called 3 times in the
sequential unit. What value is assigned to X for the third
invocation? A, B, or nothing?
Cheers,
Christian
PS: I hope this can be resolved without changing the model.
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
|