On 5/30/07, KANO, Yoshinobu <[EMAIL PROTECTED]> wrote:
Thank you for your replies.
This design proposal is fine for me.
Is it possible to implement the multiple inheritances for Apache UIMA in
this way?

Yoshinobu

J. William Murdock wrote:
> 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).
><snip/>

If creating a new JCas-like mechanism, I think we should carefully
consider aligning it with other (all?) aspects of Ecore, not just
multiple inheritance.  Some of this may require other changes in the
core CAS.

We expect the OASIS UIMA Technical Committee to decide that Ecore is
the type system represetnation for the UIMA spec, so something like
this will probably eventually be necessary for Apache UIMA to comply
with the UIMA spec.  But this raises the question of whether we should
attempt such a major piece of work to align with Ecore before or after
the OASIS TC actually releases a spec (end of this year, hopefully).

-Adam

Reply via email to