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
|
