Adam Lally wrote: > On Mon, Aug 10, 2009 at 5:32 PM, Marshall Schor<m...@schor.com> wrote: >> Adam Lally wrote: >>> On Mon, Aug 10, 2009 at 4:07 PM, Jörn Kottmann<kottm...@gmail.com> wrote: >>> >>>> Marshall Schor wrote: >>>> >>>>> The generification of FSIndex currently specifies one type, <T extends >>>>> FeatureStructure> that is the type of item being returned. >>>>> >>>>> >>>>> The contains and find methods have arguments of type FeatureStructure. >>>>> These could be changed to take type "T". >>>>> >>>>> >>>> No I do not think that they could be changed to take type T. >>>> Lets take the case of the contains method. >>>> The javadoc says: >>>> "Check if the index contains an element equal to the given feature >>>> structure >>>> according to the >>>> ordering of the index. Note that this is in general not the same as feature >>>> structure identity." >>>> and it for the param fs it says "The FS we're looking for.". There is no >>>> place where >>>> it says that contains can only be called for FSes which have the type of >>>> the >>>> index. >>>> >>>> The change of the parameter from FeatureStructure to T would also change >>>> the contract of the method a little, because then it would not be possible >>>> anymore >>>> to pass a FeatureStructure which has not type T. >>>> >>>> >>> I agree. It's sometimes useful to call FSIterator.moveTo method and >>> pass an FS of a Type other than the one that the index was defined >>> over, as part of implementing something like a subiterator. >>> >> I agree with the case where it's the "bag" index being used, because >> that uses a test which works on all feature structures. >> >> However, for Set and Sorted, the implication of passing a FS which is >> not in the type hierarchy is, according to the JavaDocs, "undefined". >> This is because the code assumes the layout of the features and their >> values is appropriate for the type. In other words, if the type of some >> key was a string, it might take a value from the main int heap and use >> it as an index into the string array - and if the int heap object was >> not the right type, it could pull an arbitrary value from that slot, and >> end up throwing an array index out of bounds exception. When I looked, >> it didn't appear to me that the code checked for any kind of type >> subsumption before proceeding... (but I may have missed it...) >> >> It could turn out that the data (whatever is being pulled) would just >> happen to "match", even though the types are different. >> >> Because this is an undefined operation that could throw various kinds of >> runtime errors, or return an equal match where none really exists, I >> think it should not be allowed, for set and sorted indexes. >> > > In the case of the AnnotationIndex, the object that you pass to > FSIterator.moveTo must be a subtype of Annotation (else you would get > all the weird effects that you describe). But it is still valid for a > user to do: > FSIndex<AnnotType1> index = cas.getAnnotationIndex(annotType1); > index.moveTo(annotType2); > > where annotType1 and annotType2 are both subtypes of uima.tcas.Annotation. > > In general, the object that you pass to moveTo() must be a subtype of > the type that was in the index definition (in the user's descriptor, > or for the case of the built-in AnnotationIndex, > uima.tcas.Annotation). > > -Adam
One concrete example of Adam's point: suppose you have a sentenceFS and a tokenIterator. Then tokenIterator.moveTo(sentenceFS) will position the token iterator at the first word in the sentence (modulo some subtleties that are beside the point here). Very useful. --Thilo
