On 1/4/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
I would propose the following changes:
- Leave createFeaturePath() and friends at the CAS. These methods
require/return CAS-specific data structures and don't need to be
accessible anywhere else.
Marshall had already moved these to CommonCas, so he must have thought
they were usable from JCas? I'll let him comment on that, it's
orthogonal to the CAS/view interface split I think.
- On CasView, remove getJCasView() and getLowLevelCasView(). Those
should be accessed from the JCas and LowLevelCas, respectively.
- Similarly, on JCasView, remove getCasView() and getLowLevelCasView().
OK, I think I agree that might be cleaner. If we do this then we
really have to add getView APIs to LowLevelCas, otherwise there would
be no way at all to access a low-level interface to a view.
- On the JCas interface, can we remove some of the APIs and just make
them available on the impl object? I'm thinking of things like
putJfsFromCaddr(int, FeatureStructure) and getType(int).
I think these may be called from JCas cover-classes, in which case I
think they need to be on the interface. Marshall?
Another open issue is the createFS method and variants. I have left
them off of the view API for now in deference to Thilo's "no
convenience methods" suggestion, but I'm still a little unsure.
Basically the situation now is if a user has a view handle and wants
to create an FS they need to do view.getCAS().createFS(...);
The upside is that it helps make it clear that FS are owned by the
CAS, not the view. The downside is that it may annoy users to have to
put in the getCAS call all the time. Also is it inconsistent that
view.createAnnotation(...) *is* on the view API? This was done so
that users can create annotations that refer to the Sofa for the view
they're operating on.
What do others think?
-Adam
