Thilo Goetz wrote:
Eddie Epstein wrote:
On 5/14/07, Adam Lally <[EMAIL PROTECTED]> wrote:
I prefer that we deprecate addToIndexes() and removeFromIndexes() but
take reasonable steps to make the methods behave is closely to the
current behavior as possible. If Marshall is willing to implement
something a little more complex that reduces the chance of breaking
annotators, then I think that would be good.
There's no question that these methods should work for single view
annotators; that is a given. To have it work for some multi-view
annotators but not others does not seem like an advantage. A warning
should be given that these methods should not be used for a multi-view
annotator.
Another thing to consider is non-JCas cover classes. Ideally all cover
classes would point at the base CAS, as all FS exist in the same heap,
shared for all views. Would be nice for both CAS and JCas cover
classes to have the same simple model.
Eddie
Sorry, stupid question from a non-Sofa aware developer. I lost the
thread of this discussion right at the start. Why does the JCas need
to know about views? Why can't it just use the view information that's
in the CAS? When I get to an annotation by dereferencing, that
annotation already lives in some given view, known to the CAS. That's
the one that needs to be used, right? I'm probably missing the point
entirely here, so please enlighten me.
--Thilo
Good questions. The only reason for JCas knowing about views are to be
able to implement methods like:
aJCasObject.addToIndexes() and aJCasObject.removeFromIndexes()
If you recall, there are 2 fields in aJCasObject: one is the "addr"
(int) of the object in the CAS array, the other is a ref to the CAS view
(it's really a ref to the instance of the _Type JCas object, which, in
turn, has a ref to the CAS view.)
The impl of addToIndexes() uses this information to determine which set
of indexes to add the fs to.
---------------------
"When you get to an annotation by dereferencing" - that's not the
issue. The issue is when you get to a *feature-structure*,
which is not an annotation. These things can be "living" in 0 or more
views, by which I mean, they can be "indexed" in 0 or
more views.
You are correct with respect to feature structures which are subtypes of
annotation-base - they can only be living (indexed)
in 0 or 1 view, and they have that extra field which can be used to
locate the view.
Please ask more questions :-)
-Marshall
