Adam Lally wrote:
On 1/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: twgoetz
Date: Tue Jan 9 06:00:11 2007
New Revision: 494413
URL: http://svn.apache.org/viewvc?view=rev&rev=494413
Log:
Jira UIMA-25: remove strange array type subsumption code.
https://issues.apache.org/jira/browse/UIMA-25
<snip/>
-1, sorry. We at least need to discuss this first. There's a reason
why that code was put there (by Marhsall, I think). I'm unpleasantly
surprised that we had no test case for this though. :-(
Ok, no problem. I tried to start a discussion about this a few weeks
back, but nobody responded. Now I guess I have your attention ;-)
As I remember it, the issue is that type-restricted subtypes of
FSArray were sort of half-implemented. So in the type system
descriptor one can declare that a feature has a range type of FSArray
whose element type is "MyType". This resulted in the dynamic creation
of a type FSArray[MyType] in the type system. But, there's no method
by which you can actually create an instance of this type.
Why don't we add CAS.createArrayFS(Type arrayType, int length)?
If you try to define a "plain old" FSArray to a feature whose range
type is FSArray[MyType], it fails on the subsumes check. So there's
no way you could ever assign anything to this feature in our current
implementation.
I think we actually had a release in this state, and when things
started breaking, tried to patch it in a maintenance release. This
was done by hacking subsumes() to return true for any FSArrays (e.g.
FSArray[MyType] subsumes FSArray *and* vice-versa), essentially making
them equivalent from an assignment perspective.
My original proposal for adding "elementType" to our type system
descriptor was that we would not enforce this restriction in the CAS
API, anyway. A slot to hold this information was needed for Ecore
compatibility, but enforcement wasn't a strict requirement. I thought
maybe we'd end up using in this JCasGen, though.
-Adam
A proper implementation of parametrized arrays has been on the agenda
for a very long time. Why not do it now? I'm not sure what you mean by
using this in JCasGen, but checked setters and getters will only work if
the underlying CAS knows about parametrized arrays as well (since you
can freely mix CAS and JCas use on the same data).
--Thilo
