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.
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.
-Adam
