JCasUtil has various methods that would be nice to have in CasUtil as well

[GoogleCodeExporter]

So far our main focus was on implementing convenience methods on the JCas 
level. Most of these would also be helpful on the CAS level, such as 
select(CAS, Type) or even select(CAS, String typename).

Original issue reported on code.google.com by richard.eckart on 15 Mar 2011 at 4:35

[GoogleCodeExporter]

Original comment by richard.eckart on 16 Mar 2011 at 1:46

[GoogleCodeExporter]

Mirrored all select* and getView methods from CasUtil in JCasUtil. Did not 
mirror the iterate* methods as I consider deprecating them. The select* methods 
return Collections and thus can be easily used in enchanced for loops as well 
as to initialize other Collections, e.g. new ArrayList(select(...)). They also 
offer a size() methods, which often comes in really useful.

Original comment by richard.eckart on 16 Mar 2011 at 3:00

• Changed state: Fixed

[GoogleCodeExporter]

I really like the iterate methods and would like to keep them.  It makes sense 
from a memory management perspective.  There actually are scenarios (esp. with 
full-text articles) where the size of a CAS can get really large and you don't 
want to load all tokens into a collection every time you want to iterate over 
them (which may be often.)  

Original comment by phi...@ogren.info on 17 Mar 2011 at 2:17

[GoogleCodeExporter]

The select methods are implemented in such as way that they return something 
that resembles a collection. Specifically something that provides iterator() 
and size(). It does not necessarily mean that the stuff is copied into an 
ArrayList or such. When possible, the select()s are implemented as efficient as 
the iterate()s. So I do not really see a point in keeping the iterate()s 
around. Indeed, I have changed a couple of them to call select() internally.

Original comment by richard.eckart on 17 Mar 2011 at 5:05

[GoogleCodeExporter]

Oh good.  Well, in that case I suggest that we deprecate them for the next 
release and remove them for the following (or whatever our convention is going 
to be.)  

Original comment by phi...@ogren.info on 18 Mar 2011 at 3:20

[GoogleCodeExporter]

I think removing them would be something for a 2.0.0 version as this is 
definitely a quite incompatible change.

Original comment by richard.eckart on 18 Mar 2011 at 3:31

[GoogleCodeExporter]

Original comment by richard.eckart on 7 Apr 2011 at 12:12

• Added labels: Milestone-1.2.0