> On 12/12/06, Adam Lally <[EMAIL PROTECTED]> wrote:
>> Maybe someone can come up
>> with a brilliant idea about how we can fix this and still support
>> migration? That would be nice.
>>
>
> 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
