|
Re: A pattern definition regarding Inheritance [message #1271184 is a reply to message #1271176] |
Fri, 14 March 2014 12:55   |
Abel Hegedus Messages: 197 Registered: September 2015 |
Senior Member |
|
|
You don't need to write this pattern if you simply want to access Sub-specific features (there is no explicit "casting" in EMF-IncQuery).
If you want a pattern where a parameter is the value of a feature defined by Sub1 or the value of a feature in Sub2, depending on whether another parameter is Sub1 or Sub2, then you can do that. E.g.:
pattern someValueFromSubclasses(sup : Super, value) {
Sub1.feat1(sup, value);
} or {
Sub2.feat2(sup, value);
}
As long as both Sub1 and Sub2 are subtypes of Super and feat1 and feat2 are the same type, this will work.
You could use subpatterns if you have to do additional checks on the object. E.g:
pattern someValueFromSubclassesSatisfyingOtherConstraints(sup : Super, value) {
find sub1SatisfyingConstraint(sup);
Sub1.feat1(sup, value);
} or {
find sub2SatisfyingConstraints(sup);
Sub2.feat2(sup, value);
}
pattern sub1SatisfyingConstraints(sub : Sub1) {
// any kind of checking on sub
}
|
|
|
Re: A pattern definition regarding Inheritance [message #1272205 is a reply to message #1271184] |
Mon, 17 March 2014 10:45   |
Emre T Messages: 119 Registered: April 2013 |
Senior Member |
|
|
Hello Abel,
this was very helpful. Just didn't know, that in such cases I don't need any explicit casting.
But a strange error has again surfaced, not directly with the approach. I am working currently on both Windows and Mac OS X systems simultaneously. There are the exact same pattern definitions (as follows) with exact same models underlying beneath them. But what on Windows works, doesn't work on Mac OS X.
The pattern definitions (I know the first one is unnecessary:)) :
pattern getSub(super: Super) {
Sub(super)
}
pattern getSubFeat(super:Super, attr: EString) {
Sub.feat(super, attr);
check(...)
}
On Windows I only get a warning, but it gets the job done: Inconsistent parameter type definition, should be ClassReferencingDecision based on the pattern definition
But on Mac OS X, I still get the previeous error and IncQuery does not generate the necessary queries: Ambiguous variable type defintions: [Sub, Super], type cannot be selected. Please specify the one to be used as the parameter type by adding it to the parameter definition.
Have you ever experienced something like this? What might be the reason for it?
Thanks!
|
|
|
Re: A pattern definition regarding Inheritance [message #1272263 is a reply to message #1272205] |
Mon, 17 March 2014 13:56   |
Emre T Messages: 119 Registered: April 2013 |
Senior Member |
|
|
And a further question, regarding this unnecessary pattern definition of Sub/Super. What if I don't want to access any features of the subtype, but I want to get the subtype itself and use it in further patterns? Trying this I always get this "inconsistent parameter" warning, which leads to errors when trying to define derived queries.
[Updated on: Mon, 17 March 2014 14:23] Report message to a moderator
|
|
|
Re: A pattern definition regarding Inheritance [message #1272665 is a reply to message #1272263] |
Tue, 18 March 2014 12:55  |
Abel Hegedus Messages: 197 Registered: September 2015 |
Senior Member |
|
|
In the semantics of the declarative query language, there are no such concepts as get or access. Instead, the pattern body contains a set of constraints, which must be satisfied by the matches of the pattern when queried over a model.
In your case, including a type constraint, such as Sub(var); will specify that the value of parameter var is always a Sub (or subtype of Sub).
Alternatively, including a path expression (which is also a constraint), such as Sub.feat1(var, value); will specify that the value of feature feat1 in the object matched to var in a given match will include the object matched to value.
If you want to have a helper pattern that only matches to objects with a given type, just use:
pattern myType(obj){
MyType(obj);
}
Do you get the error on getSub or getSuper?
|
|
|
Powered by
FUDForum. Page generated in 0.01935 seconds