Adam Lally wrote:
On 5/11/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Adam Lally wrote:
> Another thought: Is it possible to have separate instances of _Type
> for each view, but to have only one, shared, set of generators?
>
> The FSGenerator.createFS method is passed a CAS reference - is this a
> reference to the view? If so, it seems like only one generator is
> needed - it could look up the necessary _Type object from the view.
>
> -Adam
Yes, but :-)
Downside - it requires regenerating all the jcas code... So older
versions wouldn't work...
Hmm. Why do we even need individual generator classes defined in the
_Type objects? The only thing that changes in the different
generators is the actual name of the class to construct, which is
available by reflection anyway. So I think we could define just one
JCasFsGenerator class that worked for all JCas types, and JCasGen
could just stop generating the code for that. Old JCas-generated
classes would still work, we'd just ignore the generator.
Cool... out of the box thinking ... This was originally not done
because of fears that reflection was slow, but maybe that's not true in
Java anymore.
Other downside is this still "breaks" the implied contract about there
being one JCas cover object per unique CAS instance.
True. So what if we change thing so we have a single
CAS-addr-to-JCAS-instance-map? Then this code would still work:
--------------
JCas someView_1 = baseJCas.getView(name1);
JCas someView_2 = baseJCas,getView(name2);
(new MyAnnotation(someView_1)).addToIndexes();
(new MyAnnotation(someView_2)).addToIndexes();
---------------
Then what wouldn't work is something like:
-------------
MyAnnotation x = new MyAnnotation(someView_1);
someView_1.addFsToIndexes(x);
someView_2.addFsToIndexes(x);
FSIterator iterator = someView_2.getAllIndexedFS(MyAnnotation.type);
MyAnnotation y = iterator.get();
y.removeFromIndexes();
--------------
Current behavior is that y != x, and y.removeFromIndexes() removes it
from the indexes for someView_2.
Behavior if we change this so y==x is that y.removeFromIndexes() would
remove it from the indexes for someView_1.
We could make this work, even... by updating the JCasInstance - to -
view map when the iterater returns it, to always reflect the most recent
view it was "iterated" out of (sorry for that English...).
Here's a summary of this thread:
First - a universally good idea: for types which are subtypes of
Annotation, use the Sofa ref for the view (since this is the only
"legal" index to use).
Choice points:
One JCas object per Cas Object or multiple ones, one per view.
Having one makes the implied semantics of extra JCas fields work
better. Note that it is possible, when using get()/next() on an
iterator, to "update" the _Type ref to correspond to the view
associated with the iterator.
One set of _Type instances shared for all views, or one per View.
Having one per view lets the JCas instances "encode" a "preferred
view" for use in add-to/remove-from indexes, if that's desired.
The view used for addto/removeFrom indexes can be a value that is
specific to an instance, or one that is global, but changing,
according to actions such as "new" and get/next out of an iterator,
and (maybe) getView. If it specific, either we need one set of
_Type instances per View, or an extra Map from JCas Instances to views.
The most savings in space/time is acheived by
* one JCas object per CAS object
* one _Type instance shared by all views
* no map from JCas object to View (implies that the preferred view
is global, and not kept per instance)
Note that no JCasGen or Generator changes are needed with this choice,
and the generators can now be shared among views.
Backwards compatibility:
Single view things work. Multiple view things that don't have complex
interweaving probably work. The exact semantics change, perhaps for the
better. Example of better:
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();
----------------------------------------------------
After - removes from view_2, which actually might be better, because
users probably expect if they get a value from an iterator, and then
remove it, it should remove it from that index.
(Of course, if you then did a next() operation, you'd get a
ConcurrentModificationException - but that's another issue :-)
----------------------------------------------------
My current leaning is toward the "most savings" choices, with updating
the preferred view on "new", get/next from iterators, and getView().
What do you think?
-Marshall
