I was making some incorrect assumptions.
I was assuming that the parent JCasGen'd class would correspond to a UIMA type,
and the subclass would be something that extended that but didn't add any
features, or needed to get registered, etc.
The only reason to register it would be to have non-JCas creation APIs create
instances of the subclass, rather than the other class.
I was assuming that was not the case; that the user was using JCas to create
instances.
But because there's lots of things that could create instances, other than user
JCas code using the subclass, you would need a trick like Richard's suggestion.
I haven't tried this, and it's quite possible that this might or might not work
...
-Marshall
On 11/22/2016 2:31 AM, Richard Eckart de Castilho wrote:
> On 21.11.2016, at 23:12, Marshall Schor <m...@schor.com> wrote:
>> there's plenty of denseness to go around :-) I think this ought to work in
>> v2
>> as well? Can you say a scenario where it wouldn't?
> In V2, one would at least have to manually implement the typeIndexID+friends
> in the subclass, right:
>
> /** @generated
> * @ordered
> */
> @SuppressWarnings ("hiding")
> public final static int typeIndexID =
> JCasRegistry.register(NamedEntity.class);
> /** @generated
> * @ordered
> */
> @SuppressWarnings ("hiding")
> public final static int type = typeIndexID;
> /** @generated
> * @return index of the type
> */
> @Override
> public int getTypeIndexID() {return typeIndexID;}
>
>
> Cheers,
>
> -- Richard
