Jörn Kottmann wrote: > Adam Lally wrote: >> On Wed, Aug 12, 2009 at 5:54 AM, Jörn Kottmann<kottm...@gmail.com> >> wrote: >> >>> 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. >>> >>> >> >> If ClassCastExceptions are going to happen I'd *much* rather they be >> on explicit casts in user code rather than in framework code. It's >> more straightforward for the user to understand and fix the problem in >> that case. >> >> But really, it more comes down to philosophy. My understanding of how >> to use generics is that you should use them in places where the API >> guarantees it complies with the type constraint. That way it makes >> the API more understandable than just using raw types. I think that >> putting in things which may or may not work makes the API less >> understandable and is really not a good idea. I don't believe that >> using generics just to avoid having to do typecasts is the right idea >> at all. I'm not aware of cases where that has been done in the Java >> class libraries, for example - if there are, point them out. This is >> why I'm fighting tooth and nail against taking UIMA in that direction. >> >> >>> 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. >>> >>> >> >> Yes, I wouldn't strenuously object to that but I doubt it's usefulness >> for createFilteredIterator. I do think something like that is nice in >> JCas for getting an iterator over all instances of a specific type, as >> I suggested on another thread. >> > In the end that means that we can leave this method in CAS and JCas > like it is right now: > <T extends FeatureStructure> FSIterator<T> > createFilteredIterator(FSIterator<T> it, FSMatchConstraint cons); > +1 > A method like I proposed can be added to the CAS interface after the > next release if we decide > its necessary. Do we want to add the method proposed by Adam for 2.3.0 > to JCas ? Adam's suggested method proposed in another thread was:
FSIterator<T extends TOP> getAllIndexedFS(Class<T> jcasType) This method is on a particular index, or on an instance of the JFSIndexRepository (or the equivalent non-JCas one). Currently the JFSIndexRepository doesn't have methods for returning iterators picked by [Class<T> jcasType], but I think these could be easily added, and I'm +1 for this. There are also methods on the JCas itself for returning instances of AnnotationIndex public AnnotationIndex getAnnotationIndex(Type type) I would also be +1 for adding a version of this: public AnnotationIndex<T extends Annotation> getAnnotationIndex(Class<T> jcasType) I would also be +1 for adding versions of getAllIndexedFS to the JCasImpl itself, avoiding the need to do aJCas.getJFSIndexRepository().getAllIndexedFS... which I think is more an implementation detail than a needed API feature. (please correct this impression if I'm mistaken...). -Marshall > > Jörn >
