LeHouillier, Frank D. wrote:
I was certainly tripped up by it. I'm not even sure that the default behavior shouldn't be different than it is. It feels like an artifact of implementation convenience rather than something the user should expect.
I don't like the behavior, either. However, type priorities were introduced because of user requirements. They're certainly not an implementation convenience. Quite the opposite, in fact :-) Now if enough users speak up, maybe we can change something. Perhaps by default, type priorities should not be used and you'd need to do something special to activate them. One might imagine special iterator overloads that respect type priorities. The problem that type priorities are trying to address is a valid one, IMHO. I'm just not sure that the way we're tackling this is the best one.
Anyway, perhaps another solution to this problem might be suggested by the findCoverFS method in the Regex annotator. In Katrin's example you could create a dummy Abbreviation with the offsets of the entity, use FSIterator.moveTo() to get to it and add all the valid iterators you find going forward that still fall within the end offset to your list.
This is what the code in my other reply is supposed to do.
I'm not sure of the efficiency of moveTo() versus iterating through the whole list though. Is an FSIndex implemented as a hash so that searching through it for the right offsets (using moveTo()) is efficient?
The annotation indexes are implemented as balanced search trees (red-black trees). moveTo() is quite efficient. --Thilo
