• Implement your own well-behaving feature by recomputing when necessary and sending notifications. This is hard and error-prone, so not recommended, unless you have "almost" well-behaving features.
  
• Use the DerivedFeatureAdapter (see here) and register the dependencies of the method in it. This is the less intrusive if you only depend on some features and not traverse deeply into the model during calculation, however it will provide lower performance since the recalculation will happen every time a dependency changes.
  
• Reimplement your derived feature as a query-based derived feature, this is approach is described here. This can be used, if you can describe your derived feature as a query in EMF-IncQuery. The advantage of this solution over just describing your feature as a query (as Zoltán proposed) is that once you change your derived feature to query-based, it will be transparent to all EMF applications, since they can call the getter and also listen to notifications, without knowing that underneath it is handled by EMF-IncQuery.
  

However, I think this method has several disadvantages :
- It is less natural, forcing the use of 'find' instead of the dot notation
- Cascading writings are not possible, and pattern paths are broken in several code parts
- Derived features patterns have to be present in the same query file ? Did I miss somethng about some kind of inclusion or reference to patterns stored in another .eiq file ?
- Every derived features to be used must be expressed, redundantly with the metamodel implementation and thus have to be kept coherent with it.

I'd really like having a well behaving metamodel !
I'm not sure the DerivedFeatureAdapter will work well for complex derived features (computations with many hops, or filtering features).
What's your opinion ?

- Cascading writings are not possible, and pattern paths are broken in several code parts

On more question at the end:

Quote:

- Cascading writings are not possible, and pattern paths are broken in several code parts

Can you elaborate in a bit more detail on what you mean by this? How could the query language be improved?

pattern sample(a:A, d:D) {
   A.feature1.feature2.feature3(a, d);
}

pattern sample(a:A, d:D) {
   A.feature1(a, b);
   find feature2pattern(b,c);
   C.feature3(c, d);
}
pattern feature2pattern(b:B, c:C) { ... }

pattern sample(a:A, d:D) {
   A.feature1.feature2pattern.feature3(a, d);
}
pattern feature2pattern(b:B, c:C) { ... }

pattern sample(a:A, d:D) {
   A.feature1.feature2.feature3(a, d);
}
pattern feature2(b:B, c:C) { ... }

Hi,

if you can update your metamodels, then making the features well-behaving is indeed the best option to do.

One addition:
- Derived features patterns have to be present in the same query file ? Did I miss somethng about some kind of inclusion or reference to patterns stored in another .eiq file ?
No, they don't have to. Currently, we have some tooling issues that strongly suggest that they are stored in the same project (otherwise, it is possible that you end up with having the same Rete network built twice), but inter-file dependencies work inside a project.

You can either write find org.eclipse.incquery.patternName(parameters), or you could use the 'uses' declaration to import that pattern, similarly as import declarations work in case of Java programs: you simply have to import the fully qualified name of the pattern.

Cheers,
Zoltán