uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Lally <ala...@alum.rpi.edu>
Subject Re: generics: createFilteredIterator
Date Mon, 10 Aug 2009 20:56:13 GMT
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.

In general it seems to me like we only want to use generics in our API
when the API is guaranteed to actually adhere to the type constraints
that we put in the method signature.  We shouldn't use generics when
the API *sometimes* adheres to the constraints and sometimes does not.

  -Adam

Mime
View raw message