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 10:18:08 GMT
Thilo Goetz wrote:
> 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).
>   
It can work for both JCas and CAS. In the CAS case the implementation
of the method could use Class.isInstance to filter out objects which
have the wrong type.

Jörn

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