On 1/4/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Adam Lally wrote: > So I think we need to deprecate addToIndexes(). Not sure about this - because the "current view" mechanism would seem to make this work, even for multi-sofa. We could even put in code that checked if the item being indexed was a subtype of AnnotationBase, and if so, indexed it in the proper view (if the current view had a Sofa but it was the "wrong" one).
Oooh, now I realize this was even more of a problem then I thought. I was thinking of code that currently does this: process(JCas aJCas) { JCas myView = aJCas.createView("foo"); MyAnnotation annot = new MyAnnotation(myView); annot.addToIndexes(); } This indexes annot in myView. With the new refactoring the first line is now an error because the return type of createView is now JCasView. To eliminate the errors the user changes their code to: process(JCas aJCas) { JCasView myView = aJCas.createView("foo"); MyAnnotation annot = new MyAnnotation(aJCas); annot.addToIndexes(); } The original problem I had was - how do we know what view to index the annotation in. I don't think we should just add it to the current view (which would be different than myView). That seems dangerous with no deprecation warning. But I realize there's a bigger problem. In line 2 when we create the annotation, what Sofa do we point it at?? It seems like we would need to do (a) add a MyAnnotation constructor that takes a Sofa as an argument, and/or (b) add a MyAnnotation constructor that takes a JCasView instead of a JCas. Both involve changes to the user's JCas-generated code, or require them to rerun JCasGen, and would require manual updates to any user-written constructor. So that's kind of ugly. -Adam