Thilo Goetz wrote:
Adam Lally wrote:
On 1/8/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
I see two reasonable alternatives.  Neither involves a CommonCas.

a) The JCas assumes its wrapper nature.  It implements its additional
functionality, and for all base functions, users refer to the CAS.

b) The JCas extends the CAS.  For conflicting methods, use a different
method name.

I like a) better because it reflects the nature of the JCas.


The JCas currently *is* a wrapper.  I don't see that being a wrapper
implies not having forwarding functions.

As Marshall notes (b) can't work because we want to change return
types.  Now, we could have come up with different method names, but I
think it may be too late to consider doing that now.

Basically, I don't think there was any problem with the way JCas was
before CommonCas was introduced.  Why is it a problem if there are
methods with the same signature in both places?
[...]

I think there is sufficient resistance to the CommonCas, and we should undo the change. Marshall?

I don't think it would be good to undo this. It seems valuable to me to factor out common things, make more explicit what's intended to be the same, and what's intended to be different, and factoring shrinks the code base, making future maintenance easier. Of course, if we adopt the get-rid-of-JCas as a separate interface suggestion, then this goes away. I'm fine with picking a better name for it, also.

-Marshall

Reply via email to