Adam Lally wrote:
On 5/13/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Before:
---------------------------------------------------
MyAnnotation x = new MyAnnotation(someView_1);
aView_1.addFsToIndexes(x);
aView_2.addFsToIndexes(x);
// removes from view_1
aView_2.getAllIndexedFS(MyAnnotation.type).get().removeFromIndexes();
----------------------------------------------------
No, this currently removes from view 2. This is the same as the
example I gave, more or less. I think your proposal does not change
this behavior.
oops, that's right. I had forgotten that each view in the "before" case
has its own map from
CAS objects to JCas cover objects, so it would get a different cover object.
My current leaning is toward the "most savings" choices, with updating
the preferred view on "new", get/next from iterators, and getView().
Let me restate this to see if I get it right. Basically the idea is
that when addToIndexes() or removeFromIndexes() are called on a
non-annotation object, it would affect the most recently used view.
(Where to "use" a view means any of: calling getView() for that view,
creating a new FS instance off of that view, or accessing the
iterators for that view.)
Consequence of this: the following have different behavior:
(1)
JCas someView_1 = baseJCas.getView(name1);
JCas someView_2 = baseJCas,getView(name2);
MyType annot_1 = new MyType(someView_1);
annot_1.addToIndexes(); //adds to someView_1
MyType annot_2 = new MyType(someView_2);
annot_2.addToIndexes(); //adds to someView_2
(2)
JCas someView_1 = baseJCas.getView(name1);
JCas someView_2 = baseJCas,getView(name2);
MyType annot_1 = new MyType(someView_1);
MyType annot_2 = new MyType(someView_2);
annot_1.addToIndexes(); //adds to someView_2 <<<<<< CHANGED
annot_2.addToIndexes(); //adds to someView_2
(In the current implementation, annot_1.addToIndexes() would add to
someView_1 in both cases.)
It seems strange to me that the call to annot_2 = new
MyType(someView_2) would affect what happens to annot_1. I admit that
this may just be a hypothetical example and that no annotators
actually do something like this. But it just doesn't seem like the
cleanest design. If we do decide to go with this I think I would want
to deprecate the methods at the same time.
I still prefer the semantics of my alternative suggestion to use
separate _Type objects (but shared generators and instance map), with
your idea of changing the _Type ref when an object is returned from an
iterator. Then the above code example works in what I think is a more
intuitive way.
So, the view ref for a JCas instance is "sticky" with that particular
JCas instance, and
changes when it's retrieved from another iterator.
I think the final decision comes down to: is the performance savings
we expect from eliminating the duplicate _Type objects worth the risk
that we might break an annotator.
I don't think there is a significant performance savings. So I'm
willing to go with the following
(let's see if I get this right...)
Changes:
1) 1 map from CAS objects to JCas cover objects, shared by all views
2) The getters from the iterators would *update* the _Type ref to be the
view associated with the iterator
* this might be implemented by changing the generators, using
reflection, or not - TBD
3) addto/removeFrom indexes for subtypes of Annotation_base use the sofa
ptr to get the right view.
These are not changed:
4) There is a set of _Type objects, one per view
Please let me know if I've overlooked something
-Marshall
