I'm with Richard. That kind of index exists purely for purposes of the
implementation, and I'm having trouble imagining an end-user use case
that would benefit from this kind of index - a benefit that outweighs
the additional complication in the API it would bring.
--Thilo
On 21/09/15 19:01, Richard Eckart de Castilho wrote:
I find it hard to imagine a case where one would wish to avoid subtype
polymorphism during iteration. If one asked for that, I would ask in return why
subtyping was used in the first place.
And even if it were desired, a sufficiently strong case would have to emerge
that would justify a dedicated support for this over simply filtering out FSes
of subtypes during iteration.
Cheers,
-- Richard
On 18.09.2015, at 15:03, Marshall Schor <[email protected]> wrote:
The current v2 approach for indexes has a somewhat misnamed class,
FSLeafIndexImpl, which is the superclass of implementations of the 3 kinds of
indexes - bag/set/sorted.
It's not really a "leaf" in the sense of the type system; it's instead an index
over a single type, excluding any subtypes (if they exist).
UIMA supports iterators over a type + all its subtypes; there's no support for
iterating over a type **excluding** its subtypes.
This restriction appears in the API for FSLeafIndexImpl in that it does *not*
implement the FSIndex interface (which defines iterators and related operations
over indexes).
For the next major UIMA version (V3), we could change this, and allow creation
of indexes over particular types **excluding** any subtypes (if they exist).
Would this be a positive change, or not? It would increase the complexity;
would it be useful in practical applications?
-Marshall
