[
https://issues.apache.org/jira/browse/UIMA-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15485510#comment-15485510
]
Richard Eckart de Castilho commented on UIMA-1524:
--------------------------------------------------
I am a bit torn between the static methods and methods on CAS. Actually, I like
the static methods, but they require a static import. No problem for me because
I have added e.g. uimaFIT JCasUtil to the suggestion list for static methods in
Eclipse, but that's an extra action to do. Also, there is a potential clash for
static imports if static methods for CAS and JCas are defined in separate
classes as it is presently the case with CasUtil and JCasUtil.
That said, in some cases, the CAS can (and probably even should) be inferred
from the context annotation - or if not different code would probably need to
be executed depending on whether the selection happens on the same CAS (view)
or on a different one. E.g. within the same view, an index can be used to speed
up the lookup, but cross-CAS, a index scan matching on offsets might be
required. For situations where the CAS is inferred from the FS, a static method
or possibly even a method on the features structure itself would be nice, e.g.
{code}
cas.select(Token.class).map( t -> t.selectCovering(Sentence.class));
{code}
Btw. JCasUtil and CasUtil also offer static select methods that operate on
FSList and FSArray instead of CAS. I also found these quite convenient
occasionally for type-safe access to multi-valued features. Would be nice if we
could also bring those across - either again as static methods or as methods on
FSArray/FSList or maybe both.
> JFSIndexRepository should be enhanced with new generic methods
> --------------------------------------------------------------
>
> Key: UIMA-1524
> URL: https://issues.apache.org/jira/browse/UIMA-1524
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Affects Versions: 2.3
> Reporter: Joern Kottmann
>
> Existing methods should be overloaded with an additional Class argument to
> specify the exact return type. This changes make down casting of returned
> objects unnecessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
