Eddie Epstein wrote:
On 5/14/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
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
JCas objects are broken if an FS instance can belong to multiple
views, because 1) addToIndexes() is ambiguous and 2) hashed JCas
instances are not shared across views. The suggestions above do not
fix the situation for all scenarios, for example, situations where a
JCas object is retrieved from a reference.
True; no *fix* is perfect for this, so far. The question is how trade
off simplicity
of implementation, simplicity of "explanation" to users, and making it
work the
way naive users would want it to in the largest number of use-cases.
Also -see other reply in this thread about the FSRef case.
Given that there is no complicated approach that always works, a
simpler approach is called for: just have one set of xxx_Type objects,
deprecate addToIndexes() and always map it to the current view.
Is this suggestion is the same as the message
http://article.gmane.org/gmane.comp.apache.uima.devel/247
with possibly some simplification for setting *current-view*?
Is the suggestion is to have *current-view* be *fixed* for the duration
of user-code, and be
whatever the view was upon entry? That would seem to break a lot of
things, such as a sofa-aware
code doing the most basic use of this:
myView = aJCas.getView(....);
// next line trys to add to base view... fails always
(new MyJCasInstance(myView)).addToIndexes();
My preference, if we were to go down this path, would be to be guided by
the 80/20 rule - do 20 % of the effort that
covers maybe 80% of the cases, and is simple enough to be
explainable/documentable.
Can you be more specific about how "simple" you want to make things, and
how you would trade off
* simplicity of explanation to users
* % of more-likely-use-cases that would work
* simplicity of implementation
-Marshall
