Closed balazsgrill closed 12 years ago
@bergmanngabor Of course, the actual list implementation used for cache is arbitrary as long as it implements List<?>. Do you have something specific in your mind?
Another solution is to extend the cache with a hashmap just to store the index of the elements.
No, I could not figure out a sublinear solution yet.
The match -> index map is not an improvement, because O(n) indices will have to be updated after each deletion.
@bergmanngabor That is true... maybe it's worth trying other org.apache.commons.collections.list.TreeList or other custom implementation. Currently, performance is not crucial for our use-case of this class, but I will try to create some benchmarks if I have some free time.
We don't want to use apache.commons.collections in our codebase - further external dependency. For this reason, Google Guava (that contains the former Google Collections may be used).
Unfortunately google guava does not provide faster list implementations. I've modified the code to enable clients to exchange the used cache implementation by subclassing the observable list. If the default ArrayList is not appropriate, the clients can use whatever implementation they want, even TreeList. No need to depend to apache collections from IncQuery.
I'm not sure the merge was necessarily a good idea (think of Eclipse IP policies). For now, it should stay, but we should discuss this on the next meeting.
An IObservableList implementation which provides read-only access to the result set of an IncQueryMatcher. The elements of the list are instances of IPatternMatch.