Hi,
TL;DR model updates, manager events, naming games, how many listener interfaces should we have and where?
for the UPDATE part:
- I included it in the "life-cycle" interface partially because the idea of removing the update callback from matchers was already mentioned in the issue, and partially because I felt that it is part of basic set of events that are engine-wide.
- Also, the model/index/matchset events are not just a "range of events" they are in a very precise relation (matchset update includes index update includes model update). Although this may be invalidated by introducing weak relations (e.g. date > currentDate), where model and index changes may not be available.
For the IncQueryEngineManager part:
- we can add an event listener to the manager as well, although this was not initially part of the issue
For the naming of events:
- I think it is important that the name somehow signifies that the call happens before an event has occurred (dispose), or after (wipe, taint, update). This may be solved by calling dispose after we dismantled the engine, but that means on the one hand that users cannot make a last call to get matches from existing matchers, on the other hand, they can reinitialize an engine if they want...
To sum up my view of the situation, the following events are interesting for ADVANCED users in the different objects of EMF-IncQuery:
- engine manager: managed engine initialization, removal (although unmanaged engines should be private and managed engines are not disposed/removed, and we don't know when the weak reference is GCed, or do we?)
- engine: taint, wipe, dispose, matcher added
- matcher: match found/disappeared
- incrementality: model changed, index changed, match set changed
IF we use one listener interface for each of the first three levels, why shouldn't we also create a single interface for the fourth level? As you can see, I accept that the engine and the "incrementality" levels can be separated.
Cheers,
