Correct me if I'm wrong, but I think we've come full circle. I don't
like this approach since it tries to hide a fundamental change in the
way we think about CASes (from single-artifact to multi-artifact etc.)
under the current APIs. I can only restate what I said earlier: to my
mind, conceptual clarity of the APIs is more important than backward
compatility.
I'm still digesting the OASIS proposal, maybe it will shed additional
light...
Eddie Epstein wrote:
On 12/12/06, Adam Lally <[EMAIL PROTECTED]> wrote:
...
Here's a shot at a brilliant idea. Or it may be a stupid idea...
often it's a fine line between the two. :)
Create a separate CasView interface which has the index-related and
sofa-related methods. However, do not remove these methods from CAS.
Instead, only deprecate them. If someone calls one of these methods
on the CAS, we redirect this to the default view, e.g., in CASImpl we
would have:
/**
* @deprecated use getView().getFSIndexRepository() instead
*/
public FSIndexRepository getFSIndexRepository() {
return getView().getFSIndexRepository();
}
I think the effect of this should be that single-view annotators would
continue to work without code change, but would get deprecating
warnings encouraging them to change their code to call getView().
Multiple-Sofa annotators would still break because CAS.getView(String
name) would now return type CasView rather than CAS. But, at least
that's far fewer annotators that would have to be manually ported.
-Adam
This should work, very nice, but do we really want users to insert
getView() in front of many things, like
cas.getView().getFSIndexRepository() and
cas.getView().createAnnotation(..), etc?
How about using deprecation text advising just the insertion of
cas=cas.getView() at the begining of the process method?
Eddie
