uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörn Kottmann <kottm...@gmail.com>
Subject Re: generics: createFilteredIterator
Date Wed, 12 Aug 2009 14:47:41 GMT
Adam Lally wrote:
> On Wed, Aug 12, 2009 at 5:54 AM, Jörn Kottmann<kottmann@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);

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 ?

Jörn

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message