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 agree with Thilo's earlier criticism of CommonCas that this is a
visible change to the user, who may have to look in multiple places in
the JavaDoc to find what they are looking for. But doesn't that same
thing apply if these methods are removed from JCas entirely so that
the user has to use the CAS API - in fact that's worse since it's not
as obvious that they should look for methods there as it is that they
should look on the superinterface.
I don't think the code maintenance gain produced by CommonCas is that
significant - there's no code in the interfaces anyway - the only
thing we save maintenance on is the JavaDoc. And I'm not even sure if
there might be cases where you'd want the JavaDoc to be different.
The CommonCas proposal shows the problematic nature of forwarding
functions. Those common methods started out as forwarding functions,
and in the implementation, I guess they still are. Then we notice that
there are a lot of common APIs between the JCas and the CAS. Of course
there are, all those forwarding functions.
Again, I don't see why this is so "problematic".
-Adam
