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 13:57:29 GMT
Jörn Kottmann wrote:
> Thilo Goetz wrote:
>> 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?
>>   
> And we have the array types. Sure if you work with a CAS
> you certainly almost want AnnotationFS if you don't want FeatureStructure.
> But working with annotations is a common case and should work well with
> generics.
> 

Whatever.  I don't think it's worth the added complexity of
the interface, but if you feel differently, go ahead.  I'm
thinking of defecting to Scala land anyway ;-)

--Thilo

Mime
View raw message