Thilo Goetz wrote:
Yes, I hadn't thought of that. I guess it wouldn't be too hard to do,
but
it would mean a non-backward compatible change I think. And I don't
think
we're ready for that, at least not in the 2.x branch.
I think it could be done in a way that was weakly backward compatible
with the following design:
1) Leave the existing JCas implementation alone, deprecate it, and
impose a rule that types that use multiple inheritance cannot be
accessed via JCas.
2) Create a new JCas-like mechanism with a new name (e.g., "MultiJCas"),
that provides the capabilities of JCas and also multiple inheritance (by
implementing the individual types in the type system as interfaces, and
generating copies of code when needed, as per EMF).
This is only weakly backward compatible, in that it imposes some serious
obstacles to anyone hoping to add multiple inheritance to an existing
component without modifying their code much; however, it would (I
believe) at least satisfy the minimal requirements that (a) existing
systems that work would continue to work, and (b) someone building new
systems can use multiple inheritance.
If an approach like that is taken, then presumably this would be a good
opportunity to reassess other aspects of the design of JCas based on
accumulated user experience since the original JCas design (since the
"MultiJCas" would not need to be backward compatible).
- Bill Murdock (IBM internal UIMA user but not a UIMA framework
developer or official spokesperson)
