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<m...@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.
