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

Reply via email to