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
|