Excellent! I was hoping for that kind of answer :-) We'll leave out this unneeded capability, in favor of simplicity.
-Marshall On 9/21/2015 3:14 PM, Thilo Götz wrote: > 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 > >
