Jörn Kottmann wrote: > Thilo Goetz wrote: >> Jörn Kottmann wrote: >> >>> Thilo Goetz wrote: >>> >>>> 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). >>>> >>> It can work for both JCas and CAS. In the CAS case the implementation >>> of the method could use Class.isInstance to filter out objects which >>> have the wrong type. >>> >>> Jörn >>> >>> >> >> In the CAS there are only FeatureStructures and AnnotationFSs. If >> you don't generate JCas classes, you don't have Java classes for >> types. Or am I missing something? >> > And we have the array types. Sure if you work with a CAS > you certainly almost want AnnotationFS if you don't want FeatureStructure. > But working with annotations is a common case and should work well with > generics. >
Whatever. I don't think it's worth the added complexity of the interface, but if you feel differently, go ahead. I'm thinking of defecting to Scala land anyway ;-) --Thilo