I'm still not convinced. At least, I'd like to change the signature of the existing select methods and see how that affects existing Java and Groovy code. But I agree that there are good arguments ;)
Anyway, there already is a rather sensible interface in UIMA: FSIndex It implements Iterable and even has a size() method. But it doesn't go well with non-Annotation types. UIMA-2830 describes some steps I tried in pushing the existing select* API towards FSIndex, but I got stuck when non-Annotation FSes were not properly accessible because getAllIndexFS didn't return an FSIndex, just an FSIterator. I wonder if there isn't a way, possible one requiring surgery, to push uimaFIT/UIMA Core towards being able to use FSIndex when accessing non-Annotation FSes. And that might again be something for an UIMA 3.0.0… -- Richard Am 08.08.2013 um 21:19 schrieb Marshall Schor <[email protected]>: > > On 8/8/2013 3:06 PM, Richard Eckart de Castilho wrote: >> Am 08.08.2013 um 20:33 schrieb Marshall Schor <[email protected]>: >> >>> On 8/8/2013 12:06 PM, Richard Eckart de Castilho wrote: >>>> The methods returned Iterable in earlier versions of uimaFIT, but the >>>> ability to >>>> get the number of annotations of the selected type or to check if it was >>>> (non-)empty >>>> was sufficiently common that it has been changed to Collection. >>> It's possible to have the method return a class which implements Iterable, >>> and >>> has the additional functions, of course; it would not need to implement >>> Collections. >> I'd like to point out that the "destructive" methods of collections >> (basically those that >> UIMA iterators currently don't work well with) are optional. Them throwing >> an >> UnsupportedOperationException is part of the Java Collection API. So >> departing from a >> standard API may not be worth the removal of these optional signatures. >> >> >> [1]: The "destructive" algorithms contained in this class, that is, the >> algorithms that modify the collection on which they operate, are specified >> to throw UnsupportedOperationException if the collection does not support >> the appropriate mutation primitive(s), such as the set method. >> >> >> I'm not convinced yet… > :-) > > I agree the "is empty" is do-able. The size - I don't know how that could be > made fast, without some major surgery. The iterators work by having each > iterator instance be a set of iterators - one for the "type" plus one for each > subtype of "type", and arranging all of them to work together. > > Having a custom class might also help in allowing other kinds of operations > (move forward, move backwards) that the FSIterators allow, which are not in > Java > iterators. > > And, the FSIterators also have a "find" method that sometimes is fairly > efficient. > > So - 2 arguments for custom class / interface vs. Collections: a) can't > usefully implement most of the collections methods (without causing some > surprises), and b) may be useful to implement other methods. > > -Marshall >> >> -- Richard >> >> [1] http://docs.oracle.com/javase/6/docs/api/java/util/Collections.html >
