| [Xcore] access field instead of getter [message #1759756] |
Tue, 18 April 2017 04:51  |
Eclipse User |
|
|
|
In my DSL I am using a boolean property which is set true if a keyword occurs. The keyword should mark this element as invalid which means the element can be used in cross-references but a validator will generate a warning (like @Deprecated in Java)
GroupRule returns Group:
(invalid?="@Invalid")?
name=ID "{"
(groups+=GroupRule)*
...
In my case groups can be nested so I needed to check if the parent group (eContainer) is invalid as well
So I defined the following in Xcore
class Group
boolean invalid
derived boolean valid get {
!invalid && (eContainer instanceof Group && (eContainer as Group).valid)
}
Unfortunately this model is not very safe: if someone calls invalid in a generator for example the invariant check parent group for validity isnt applied.
So I tried to override the generated getter for invalid and skip the derived valid.
class Group
boolean invalid get {
this.invalid && (eContainer instanceof Group && (eContainer as Group).invalid)
}
Unfortunately the generated GroupImpl will calls this.invalid() method instead of accessing the field.
I know that Xcore doesnt support everything which would be possible in Java. I assume I have to fall back to an Xtend-extension method but I hope that there is a way to define this kind of rules in my model.
|
|
|
|
|
|
| Re: [Xcore] access field instead of getter [message #1759765 is a reply to message #1759759] |
Tue, 18 April 2017 05:37  |
| Eclipse User |
|
|
|
No you can't move things, only repost them, but I see the questions in this forum too. As you say, Xcore has its limitations. So, for example, the body of any operation or derived accessor is effectively scoped/compiled against the API (interface) of that XClass, so things that are visible only in the actual Impl class are not visible in the bodies. E.g., fields, or protected methods or anything else not visible in the interface (even suppressed visibility features).
I'm not actually sure what exactly you're trying to express. It seems you model @Invalid explicitly, so you need something that models exactly this state, without derivation based on containers. And that you need a different operation that determines "effectively valid" based on the explicit state of the Group itself and the explicit state of each containing Group. But that's what you did with your first example, which you say isn't very safe in a generator, but I don't understand why that's a problem. Of course the overall derived computation depends on the overall state at that point in time...
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05589 seconds
Home