uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thilo Goetz <twgo...@gmx.de>
Subject Re: generics: createFilteredIterator
Date Wed, 12 Aug 2009 10:09:22 GMT
Jörn Kottmann wrote:
> Adam Lally wrote:
>> On Fri, Aug 7, 2009 at 2:32 PM, Marshall Schor<msa@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).

--Thilo

Mime
View raw message