Jörn Kottmann wrote: > Adam Lally wrote: >> On Fri, Aug 7, 2009 at 2:32 PM, Marshall Schor<m...@schor.com> wrote: >> >>> The createFilteredIterator method in CASImpl takes an FSIterator and an >>> FSMatchConstraint, and returns another iterator. >>> >>> The generification of this is: >>> public<T extends FeatureStructure> FSIterator<T> >>> createFilteredIterator(FSIterator<T> it, FSMatchConstraint cons) { >>> return new FilteredIterator<T>(it, cons);} >>> >>> This means that the type of the objects being returned will be the same >>> as the type of the objects of the iterator passed in. >>> >>> If the effect of the filtering is to filter the first iterator down to a >>> subset of the types of the original, this cannot be represented with >>> this signature. >>> >>> An alternate generification might be as follows, with type T being the >>> type the input iterator gives out, and U being the type the filtered >>> iterator produces: >>> >>> public<T extends FeatureStructure, U extends T> FSIterator<U> >>> createFilteredIterator(FSIterator<T> it, FSMatchConstraint cons) { >>> return new FilteredIterator<T, U>(it, cons);} >>> >>> with the corresponding changes to the class FilteredIterator, and the >>> CAS interface (to match this new signature). >>> >>> With these changes, users can write code: >>> public static void t3(CAS aCas, FSIterator<FeatureStructure> it, >>> FSMatchConstraint cons) { >>> FSIterator<Subtype> s = aCas.createFilteredIterator(it, cons); >>> } >>> >>> Without these changes, users would be forced to have the filtered >>> iterator's generic type always equal to the original type. >>> >>> Is this something we should change (given that we only get one chance to >>> do our generification)? >>> >>> >> >> I'm not sure. This user's code would compile regardless of whether >> the FSMatchConstraint actually implemented the subtype constraint or >> not. It's quite possible that the code would compile and then fail >> with a ClassCastException. >> > Yes, but if someone writes it intentional he would get the same > exception during class casting. That means not doing it would only help > someone who picks the wrong type for the variable by accident, since its > likely that > the code cannot run it will fail immediately. > > Another option would be to add a new createFilteredIterator method which > takes a Class object as argument and then reduces its output to objects > which > have the type of the class. > > <T extends FeatureStructure> FSIterator<T> createFilteredIterator(..., > Class<T> type) > > Since it only returns objects of the correct type T it should not fail. > > Jörn >
That would work only for the JCas, obviously. However, the JCas does not use Java classes to represent UIMA types (there's probably a good reason for that, but I don't know what it is). --Thilo