Adam Lally wrote:
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.
Solution 1:
How about always passing in a JCasView object? For unaware components,
this would be the view to use. For view aware components, this would be
some view (perhaps picked in a similar way), but the user code would be
expected to use this or change to other views and use those.
The new MyAnnotation( ....) would be changed to take JCasViews as the
object.
The featureStructure.addToIndexes() could work if the Java cover object
cas/jcas ref object pointed to the view. For JCas cover objects, we could
keep this pointing to separate instances of the JCas _Type objects, but
that might
get a bit expensive - we'd need to have separate instanced of the _Type
objects
for each view (but that's how it's working today). For giant type
systems, (1000 types),
that's a lot of stuff to create - but maybe there's a "lazy" way to
delay creation and
only create those that are actually "used". This would involve I think
modifying the
generator code to allow the generator to be absent, and created on first
need.
---------------
Solution 2:
General problem:
new Annotation and add/removeTo/FromIndexes need additional argument:
- the Sofa for Annotation and
- the index-set (or view) for the add/removeTo/FromIndexes
sofa/view-unaware components want to ignore this issue (for simplicity).
How about a new framework method that lets
users set the current view/sofa? This follows the use case that normal
view-aware code works with one view at a time, in terms of adding/removing
information. It has a bad aspect of being a bit indirect, and
side-effect-ish.
So I don't think I like it as much. But here's what it might look like:
Old code, not-aware:
process(JCas aJCas) {
MyAnnotation annot = new MyAnnotation(aJCas);
annot.addToIndexes();
}
- process method takes a JCas, not a JCasView
- use the "current-view" (a new concept in the CAS/JCas object which
refs the current view)
to identify which Sofa to use for the 2nd line
- use the "current-view" to identify which index-set to use for the
3rd line.
For view-aware:
process(JCas aJCas) {
aJCas.newFrameworkMethodToSetCurrentViewAndCurrentSofa(viewToUse,
sofaToUse);
MyAnnotation annot = new MyAnnotation(aJCas); // uses sofaToUse value
annot.addToIndexes(); // uses viewToUse value
}
With this, no redo of current JCasGen-erated code is needed.
But some redo of JCasGenerated code is needed in any case, and the
migration tool might
be able to do other needed changes.
-Marshall
