| Re: [henshin-dev] SequentialUnit extensions |
|
For simplicity, I would stick with your first solution using boolean
attributes. cheers, christian Am 15.07.2011 20:50, schrieb Stefan Jurack: Hi all, I wonder whether there are no complains or consents in extending the sequential unit semantics?! However, I am still struggling with myself about whether and how to realize this as there are several ways to do that. One suggestion has already been made in the previous post (see below), i.e., the addition of two attributes. A second suggestion would be to introduce only one attribute typed over an Enum with (UNSTRICT, STRICT and ROLLBACK) literals with STRICT meaning abortion without undo/rollback. A third solution would be to introduce new units with their own semantics. At least it seems quite clear to me that such semantics would improve the usability of our language. Moreover, there have already been requests about such semantics in the past. Regards, Stefan PS: Has anyone noted my proposition regarding a dedicated ForEach-Unit in our forum?! I am pretty convinced that this is hell of a good idea ;-) Am 13.07.2011 15:16, schrieb Stefan Jurack:Hi, I'm planing to extend SequentialUnit by two boolean attributes "rollback" and "strict" which have "true" as default. This being said in advance: The semantics remain as is using the default values. If "strict=true", an inapplicable rule/unit leads to an interruption of the sequential application and a return value of "false" (meaning not successfully applied unit) Otherwise, "strict=false", even inapplicable rules/units will not break the sequential unit, i.e., the unit does not care if applicable or not and tries to apply all containees one after the other. Consequently, *unstrict* sequential units return always "true" (i.e., are always successful). If "rollback=true" a rollback is performed on interruptions. This option makes only sense if "strict=true". If "rollback=false", no rollback is performed at all. If anyone disagrees with these modifications or have wishes according to the names or whatever, please speak now or forever hold your peace! ;-) Regards, Stefan PS: Code modifications would be minimal!_______________________________________________ henshin-dev mailing list henshin-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/henshin-dev |