On Wed, Aug 12, 2009 at 3:08 PM, Marshall Schor<m...@schor.com> wrote: > 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...). >
+1 to all. BTW, see here for an implementation I posted previously of a method for returning an Iterable over a specfic FS type. Of course we can also have a method that returns the iterator itself. http://www.mail-archive.com/uima-dev@incubator.apache.org/msg04657.html -Adam
