On 1/9/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
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 ;-)
Sorry, that must have slipped through without my noticing.
> > 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)?
Are there other issues with dynamic creation of new types after the type system has been "committed"? I recall that this broke some other code that Marshall had to work around, although maybe this has been sufficiently addressed at this point - I'm not sure. Also I think this may impact the C++. Eddie?
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).
I guess in general I'm not opposed to the idea of parameterized arrays. It may cause incompatibility, however, for those who are currently declaring the parameterized arrays in their type systems. One idea, if we're going to do a proper implementation, is to change the descriptor syntax to be like this:<rangeTypeName>FSArray[MyAnnotation]</rangeTypeName>. Then we could deprecate the <elementType> descriptor element and have our implementation ignore it, and that way wouldn't break assignment compatibility for those who were using it. I'm not sure exactly how JCasGen would use this, just that Marshall though that it could. It's true that if we only enforce this in JCas, someone using the CAS interface could "corrupt" the data such that it wouldn't work through the JCas, which I agree is not good. Of course the converse is also true - if we implement parameterized arrays in CAS we need to also do it in JCAS. Do we have enough runway to sufficiently explore all the issues and implement this in 2.1? -Adam
