[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [henshin-dev] Last-minute model change suggestion
|
No. The default value is false. This is overriden by the result of the
then- or else-unit. if there is no such unit the default value won't be
overriden and therefore the whole unit returns false. The only
difference between interpreting the then- and else-case is that there is
an additional check if an else-unit is present. I would expect the same
behavior from the then-branch, if it could be empty.
I'm not sure if it is reasonable to allow empty branches in
ConditionalUnits at all. I would introduce a new Unit NegatedUnit, that
holds exactly one subUnit and negates its result. This would allow to
produce the behavior of a ConditionalUnit with empty then-unit by
negating the first subUnit in a strict SequencialUnit. I would prefer to
increment the else-units lowerBound, so ConditionalUnits can only be
used to model real/existing alternatives. This would eliminate semantic
redundancy: A strict/no-rollback SequentialUnit s with two subUnits a
and b is equivalent to a ConditionalUnit holding the a as if-unit and b
as then-unit. Wrapping a in s with a NegationUnit would correspond to a
ConditionalUnit with a as if-unit and b as else-unit.
Regards,
Gregor
Am 03.02.2012 12:44, schrieb Christian Krause:
I have no objection to changing the multiplicity for the then to 0..1.
I think it should be consistent with the else part.
What is the semantics implemented in the interpreter if one of them is
null? I would guess that the unit simply succeeds without performing
any action. Correct?
Cheers,
Christian
On 02/03/2012 11:09 AM, Riegerf@xxxxxxxxxxxxxxxxxxxxxxx wrote:
Hi everyone,
just a quick question/suggestion for a last-minute model change:
Currently, the ConditionalUnit's then requires a subunit, whereas the
else can have 0..1 subunits. Can we change this so both then and else
can have 0..1 subunits? This would require only very minimal code
modification and greatly increase expressivity.
Felix
_______________________________________________
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