Hi Gregor,
thanks for the description of the workaround. I have to deal with
the possibility that someone tries to specify a scenario with
multiple invocations of the same unit with different parameters (not
only in sequential units) in the graphical editor though. For now, I
think I will encode this information using the order of
ParameterMappings -- thats the best we can do at this stage.
cheers,
christian
Am 15.01.2012 00:39, schrieb Gregor Bonifer:
I see your point. Those changes are too extensive for now.
As starting point of this discussion you illustrated a scenario
which does not work with the current interpretation. However there
is a workaround by means of the existing interpretation:
Given a Unit U with parameter X. You want a sequence which invokes
U twice with different values for X. Using a SequentialUnit S with
Parameters A and B which has U as subUnit twice won't work because
there would be two ParameterMappings initializing the *same*
parameter X (A -> X and B -> X). If you create a wrapper W
for U (e.g. a SequentialUnit with U as subUnit, a parameter WP and
a mapping WP -> X ) and replace one occurance of U in S the
subUnits would become virtually *different*. So the subUnits of S
would be U and W. Those have *different parameters* which can be
initialized without creating conflicting ParameterMappings(A ->
X and B -> WP).
I attached the mail in which I sketched the result (I used two
wrappers there).
The existance of a workaround should at least allow us to avoid
any makeshift solution. Especially since I am sceptical that a
good solution will be found as long as the primary rationale is to
not change the model.
Regards,
Gregor
Am 14.01.2012 20:13, schrieb Christian Krause:
Hi Gregor,
Am 14.01.2012 17:46, schrieb Gregor Bonifer:
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.
I do not consider this as "fatal". It is a workaround -- true.
But at least we won't have to change anything in the model, and
the additional ParameterMappings in the migrated models are not
as bad as you say.
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.
I'm not convinced yet that it works and as I said before, I
would find it good if we could solve this issue without invasive
model changes.
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.
We have to deal with the fact that we have an existing model,
that people *are* using it right now and that all bigger
structural changes make the migration more complex and
error-prone and that people might get confused and even mad if
we make such radical changes. We have to live with most of the
design decisions made already in the beginning of the project.
I'm not saying we should not think and talk about it, but I
believe the code base is not yet mature enough to plan a
"Henshin2" if you will.
So I think it is the best if we stick to small and local changes
for now and postpone discussions about more general questions
and future directions. Please keep also in mind that the next
release is planned for in 6-8 weeks and that we still have to do
a lot of work to finish the things on our current agenda.
Cheers,
Christian
PS: We avoided containment of units in order to be able to reuse
them. There are always pros and cons...
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
_______________________________________________
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
|