[
https://issues.apache.org/jira/browse/UIMA-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Eckart de Castilho updated UIMA-2830:
---------------------------------------------
Fix Version/s: (was: 2.2.0uimaFIT)
2.3.0uimaFIT
> Expose FSIterator via (J)CasUtil.select*() methods where applicable
> -------------------------------------------------------------------
>
> Key: UIMA-2830
> URL: https://issues.apache.org/jira/browse/UIMA-2830
> Project: UIMA
> Issue Type: Improvement
> Components: uimaFIT
> Reporter: Richard Eckart de Castilho
> Assignee: Richard Eckart de Castilho
> Priority: Minor
> Fix For: 2.3.0uimaFIT
>
>
> Some of the uimaFIT (J)CasUtil "select" methods work directly on an FSIndex
> or FSIterator. In those cases, it would be nice if the methods didn't just
> return a Collection, but some FSCollection<T> in which the iterator() method
> returns an FSIterator<T>.
> At least in those cases were an AnnotationIndex is used, it would be possible
> to actually return something that implements Collection<T> and FSIndex<T>, so
> it can be used in constructors like new ArrayList(...), in modern-style for
> loops, and for type-save access to the index.
> In those cases were an FSIterator is used because the type searched for is
> not an annotation, the FSIndex<T> interface is not a good choice, because it
> contains several methods that cannot be implemented based only on FSIterator.
> So maybe two interfaces: FSCollection<T> based on FSIterator and
> AnnotationCollection<T> based on FSIndex/AnnotationIndex.
> This mainly exposes more details of UIMA AnnotationIndex via CasUtil.
> JCasUtil's select method doesn't make a different between FSes that inherit
> from AnnotationFS or not. Here, the only benefit is getting access to an
> FSIterator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
