Jörn Kottmann wrote: > Marshall Schor wrote: >> Jörn Kottmann wrote: >> >>> Marshall Schor wrote: >>> >>>> OK - sounds like this won't be on the fix list for 2.3.0 ;-) >>>> And, given the value of being able to do this in selected cases, it >>>> doesn't sound right, either, to change the arguments to find, moveTo, >>>> etc from FeatureStructure. >>>> So let's leave this as is. >>> I created a jira issue to change moveTo back to FeatureStructure >>> argument, >>> it was not changed yet because I misunderstood you. >>> >>> Which other methods are you referring to ? >>> >> >> The other methods that take a FeatureStructure for purposes of >> specifying a location in an index: >> >> For these, I'm not sure if the test for equality includes testing that >> the "types" are the same, or just is testing (for sorted and set >> indexes) that the declared "keys" are "equal". >> >> The methods are: >> >> contains >> find >> compare (although the javadoc says the result is undefined if the FS's >> are not of the type of the index, but I wonder if that's checked?) >> iterator(fs) >> > > Here are the declarations of these methods: > > boolean contains(FeatureStructure fs); > FeatureStructure find(FeatureStructure fs); > Maybe we should return T here ? +1, since FSIndex which has this method is already parameterized on T - it should be returning only things of type T. > > FeatureStructure find(FeatureStructure fs); > I think it makes sense to return a FS of type T here. +1 > > int compare(FeatureStructure fs1, FeatureStructure fs2); > If we use T here, it would enforce the API specification a little, > because at least the java type must match. I think we should keep this, because it could change the behavior in this case:
Suppose you have an index over Token, and you have an instance of Sentence, and want to see if a token is in a sentence. Assuming the Token index uses the same keys as the base Annotation Index, doing a compare between Token and Sentence would be useful and make sense. -Marshall
