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 11:47:12 GMT
Jörn Kottmann wrote:
> 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
> 

In the CAS there are only FeatureStructures and AnnotationFSs.  If
you don't generate JCas classes, you don't have Java classes for
types.  Or am I missing something?

--Thilo

Mime
View raw message