Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [henshin-user] Creating "same" edge as "forbid" and "create"
Dear Matthias,

Am 23.07.2016 um 18:51 schrieb Matthias Tichy:
Dear all,

Am 23.07.16 um 14:33 schrieb Daniel Strüber:
I have committed a fix [1] that addresses this particular edge case: a
newly added edge between two <<preserve>> nodes with a <<forbid>> edge
between is now set to <<create>> rather than <<preserve>>, which is the
only meaningful option in this case. Using this fix, the editor should
work in your example as intended.

[1] https://git.eclipse.org/r/#/c/77804/

@ Committers: Can someone check and give a +1?


I am not super sure whether fixing one edge case with special code for another edge case is a good idea.
Good point, I see the general problem about that.

However, I noticed that in this case the patch addresses a more fundamental issue: our meta-model does not support parallel <<preserve>> and <<forbid>> edges in the first place, as it does not provide a means to specify that the NAC-edge has a seperate identity from the LHS-edge (in particular, we don't have edge mappings). Edges with identical source and target nodes are assumed to be identical, so the NAC-edge is interpreted as a copy of the LHS-edge.

Therefore, even without the clean-up, the contraintutive behavior that Joel observed is an accurate representation of what's going on: creating a <<preserve>> effectively removes the <<forbid>> edge. The fix helps avoid this behavior by not creating a <<preserve>> edge, but a <<create>> edge.

(For completeness, the clean-up is what breaks undo/redo, as it removes the redundant NAC in a dirty manner, without using a command. The fix avoids this issue as a side-effect.)

Particularly, i am not sure whether the code works always as intended, e.g., if you have complex nested conditions.
It is specified and implemented for <<forbid>> edges. This includes edges in multiple NACs/PACs connected by boolean operators, and excludes edges in nested application condition graphs of nesting depth >=2 (which are not supported by the graphical editor anyways). As the code only changes the default behavior, I don't think it can break something that would otherwise work.

I think a better solution would be to remove the special clean up functionality and instead work with validations and provide the special clean up functionalities as quick fixes. Then the user can decide on the correct solution.

What do you think?
I like the idea of providing better validation and quick fix support a lot - currently, we don't have any quick fixes at all. This is a long-term goal that could be addressed in the context of a student project  - it's on my to-do list now.

Since I'm not sure about the short-term implications of just removing the clean-up functionality without fully replacing it with quick-fixes (the code is rather sophisticated), I still would like to go ahead with the fix to enable the support for parallel <<create>> and <<forbid>> edges.

Regards,
Daniel






Cheers,

mtt 



_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-user


-- 
Dr. rer. nat. Daniel Strüber, Dipl.-Inf.
Software Engineering Research Group
Philipps-Universität Marburg, Germany

Back to the top