You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Jörn Kottmann <ko...@gmail.com> on 2009/08/25 10:51:53 UTC
generics: AnnotationIndex.subiterator
FSIterator<T> 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
Posted by Thilo Goetz <tw...@gmx.de>.
Jörn Kottmann wrote:
> FSIterator<T> 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
Posted by Marshall Schor <ms...@schor.com>.
Thilo Goetz wrote:
> Marshall Schor wrote:
>
>> Thilo Goetz wrote:
>>
> [...]
>
>>> I see. The subiterator generification is wrong. In the
>>> constructor, it shouldn't be
>>>
>>> Subiterator(FSIterator<T> it, T annot, final boolean ambiguous, final boolean
>>> strict) {
>>>
>>> but instead
>>>
>>> Subiterator(FSIterator<T> 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
>>>
>>>
>>>
>>>
>
>
>
Re: generics: AnnotationIndex.subiterator
Posted by Thilo Goetz <tw...@gmx.de>.
Marshall Schor wrote:
>
> Thilo Goetz wrote:
[...]
>> I see. The subiterator generification is wrong. In the
>> constructor, it shouldn't be
>>
>> Subiterator(FSIterator<T> it, T annot, final boolean ambiguous, final boolean
>> strict) {
>>
>> but instead
>>
>> Subiterator(FSIterator<T> 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
Posted by Marshall Schor <ms...@schor.com>.
Thilo Goetz wrote:
> Jörn Kottmann wrote:
>
>> Jörn Kottmann wrote:
>>
>>> FSIterator<T> 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 FSIterator<AnnotationFS> subiterator(AnnotationFS annot, boolean
>> ambiguous, boolean strict) {
>> return new Subiterator<AnnotationFS>(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 FSIterator<T> subiterator(AnnotationFS annot, boolean ambiguous,
>> boolean strict) {
>> return new Subiterator<T>(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(FSIterator<T> it, T annot, final boolean ambiguous, final boolean
> strict) {
>
> but instead
>
> Subiterator(FSIterator<T> 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
Posted by Thilo Goetz <tw...@gmx.de>.
Jörn Kottmann wrote:
> Jörn Kottmann wrote:
>> FSIterator<T> 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 FSIterator<AnnotationFS> subiterator(AnnotationFS annot, boolean
> ambiguous, boolean strict) {
> return new Subiterator<AnnotationFS>(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 FSIterator<T> subiterator(AnnotationFS annot, boolean ambiguous,
> boolean strict) {
> return new Subiterator<T>(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(FSIterator<T> it, T annot, final boolean ambiguous, final boolean
strict) {
but instead
Subiterator(FSIterator<T> 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
Posted by Jörn Kottmann <ko...@gmail.com>.
Jörn Kottmann wrote:
> FSIterator<T> 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 FSIterator<AnnotationFS> subiterator(AnnotationFS annot,
boolean ambiguous, boolean strict) {
return new Subiterator<AnnotationFS>(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 FSIterator<T> subiterator(AnnotationFS annot, boolean
ambiguous, boolean strict) {
return new Subiterator<T>(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