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. -Adam
