generics: AnnotationIndex.subiterator
FSIteratorT subiterator(AnnotationFS annot); Is that correct ? It leads to a problem in the Subiterator class, because it calls moveTo(annot) on an FSIterator, but annot must not have type T. Jörn
Re: generics: AnnotationIndex.subiterator
Jörn Kottmann wrote: FSIteratorT subiterator(AnnotationFS annot); Is that correct ? It leads to a problem in the Subiterator class, because it calls moveTo(annot) on an FSIterator, but annot must not have type T. Jörn Can you provide a little more context? I don't understand what the issue is. --Thilo
Re: generics: AnnotationIndex.subiterator
Jörn Kottmann wrote:
FSIteratorT subiterator(AnnotationFS annot);
Is that correct ?
It leads to a problem in the Subiterator class, because it calls
moveTo(annot) on an FSIterator, but annot must not have type
T.
The AnnotationIndexImpl has this method
public FSIteratorAnnotationFS subiterator(AnnotationFS annot,
boolean ambiguous, boolean strict) {
return new SubiteratorAnnotationFS(this.index.iterator(), annot,
ambiguous, strict);
}
if now the AnnotationFS is replaced by a T which is defined as T extends
AnnotationFS then,
the method is changed to
public FSIteratorT subiterator(AnnotationFS annot, boolean
ambiguous, boolean strict) {
return new SubiteratorT(this.index.iterator(), annot, ambiguous,
strict);
}
which leads to a compile error because Subiterator expects annot to be
of type T and not of
type AnnotationFS. Subitertor calls on the passed iterator moveTo(annot)
which creates a
conflict here.
Jörn
Re: generics: AnnotationIndex.subiterator
Jörn Kottmann wrote:
Jörn Kottmann wrote:
FSIteratorT subiterator(AnnotationFS annot);
Is that correct ?
It leads to a problem in the Subiterator class, because it calls
moveTo(annot) on an FSIterator, but annot must not have type
T.
The AnnotationIndexImpl has this method
public FSIteratorAnnotationFS subiterator(AnnotationFS annot, boolean
ambiguous, boolean strict) {
return new SubiteratorAnnotationFS(this.index.iterator(), annot,
ambiguous, strict);
}
if now the AnnotationFS is replaced by a T which is defined as T extends
AnnotationFS then,
the method is changed to
public FSIteratorT subiterator(AnnotationFS annot, boolean ambiguous,
boolean strict) {
return new SubiteratorT(this.index.iterator(), annot, ambiguous,
strict);
}
which leads to a compile error because Subiterator expects annot to be
of type T and not of
type AnnotationFS. Subitertor calls on the passed iterator moveTo(annot)
which creates a
conflict here.
Jörn
I see. The subiterator generification is wrong. In the
constructor, it shouldn't be
Subiterator(FSIteratorT it, T annot, final boolean ambiguous, final boolean
strict) {
but instead
Subiterator(FSIteratorT it, AnnotationFS annot, final boolean ambiguous,
final boolean strict) {
because the annotation that defines the range of the subiterator
does not have to be (and usually is not) of the same type as
the iterator. Does that make sense? This is like the case with
moveTo() that we discussed.
--Thilo
Re: generics: AnnotationIndex.subiterator
Thilo Goetz wrote:
Jörn Kottmann wrote:
Jörn Kottmann wrote:
FSIteratorT subiterator(AnnotationFS annot);
Is that correct ?
It leads to a problem in the Subiterator class, because it calls
moveTo(annot) on an FSIterator, but annot must not have type
T.
The AnnotationIndexImpl has this method
public FSIteratorAnnotationFS subiterator(AnnotationFS annot, boolean
ambiguous, boolean strict) {
return new SubiteratorAnnotationFS(this.index.iterator(), annot,
ambiguous, strict);
}
if now the AnnotationFS is replaced by a T which is defined as T extends
AnnotationFS then,
the method is changed to
public FSIteratorT subiterator(AnnotationFS annot, boolean ambiguous,
boolean strict) {
return new SubiteratorT(this.index.iterator(), annot, ambiguous,
strict);
}
which leads to a compile error because Subiterator expects annot to be
of type T and not of
type AnnotationFS. Subitertor calls on the passed iterator moveTo(annot)
which creates a
conflict here.
Jörn
I see. The subiterator generification is wrong. In the
constructor, it shouldn't be
Subiterator(FSIteratorT it, T annot, final boolean ambiguous, final
boolean
strict) {
but instead
Subiterator(FSIteratorT it, AnnotationFS annot, final boolean ambiguous,
final boolean strict) {
because the annotation that defines the range of the subiterator
does not have to be (and usually is not) of the same type as
the iterator. Does that make sense? This is like the case with
moveTo() that we discussed.
Would it be better to allow the 2nd argument to Subiterator (annot) be
? extends AnnotationFS ?
-Marshall
--Thilo
Re: generics: AnnotationIndex.subiterator
Marshall Schor wrote:
Thilo Goetz wrote:
[...]
I see. The subiterator generification is wrong. In the
constructor, it shouldn't be
Subiterator(FSIteratorT it, T annot, final boolean ambiguous, final
boolean
strict) {
but instead
Subiterator(FSIteratorT it, AnnotationFS annot, final boolean ambiguous,
final boolean strict) {
because the annotation that defines the range of the subiterator
does not have to be (and usually is not) of the same type as
the iterator. Does that make sense? This is like the case with
moveTo() that we discussed.
Would it be better to allow the 2nd argument to Subiterator (annot) be
? extends AnnotationFS ?
What would be the difference?
-Marshall
--Thilo
Re: generics: AnnotationIndex.subiterator
Thilo Goetz wrote:
Marshall Schor wrote:
Thilo Goetz wrote:
[...]
I see. The subiterator generification is wrong. In the
constructor, it shouldn't be
Subiterator(FSIteratorT it, T annot, final boolean ambiguous, final
boolean
strict) {
but instead
Subiterator(FSIteratorT it, AnnotationFS annot, final boolean ambiguous,
final boolean strict) {
because the annotation that defines the range of the subiterator
does not have to be (and usually is not) of the same type as
the iterator. Does that make sense? This is like the case with
moveTo() that we discussed.
Would it be better to allow the 2nd argument to Subiterator (annot) be
? extends AnnotationFS ?
What would be the difference?
hmm, I see - I think that normal up-casting of an argument of say,
type Sentence (which has a supertype of AnnotationFS) would work OK.
This is because the argument is not a collection...
So - I agree - it's fine using AnnotationFS as the type of the 2nd arg.
-Marshall
where anInstanceOfTypeSentence was an instance of the JCas cover class
for Sentence.
-Marshall
--Thilo
