[jira] [Commented] (UIMA-4663) UV3 Represent Feature Structures as Java Objects

["Richard Eckart de Castilho (JIRA)" <de...@uima.apache.org>]

    [ https://issues.apache.org/jira/browse/UIMA-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14983331#comment-14983331 ] 

Richard Eckart de Castilho commented on UIMA-4663:
--------------------------------------------------

Is there a reason not to stick to the usual Java naming-conventions ("get_id()" vs. normally "getId()")? If you try to lift non-feature accessors out of the bean conventions, maybe a non getter/setter method would be a better option, e.g. simply "id()".

> UV3 Represent Feature Structures as Java Objects
> ------------------------------------------------
>
>                 Key: UIMA-4663
>                 URL: https://issues.apache.org/jira/browse/UIMA-4663
>             Project: UIMA
>          Issue Type: Story
>          Components: Core Java Framework
>            Reporter: Marshall Schor
>
> Switch the storage model for Feature Structures to align with Java's Object Model, while preserving backwards compatibility.  
> This allows garbage collection of Feature Structures.
> There is likely a performance benefit by having the data in one place only, with no conversions needed between the Java world and the data-on-the int-heap world of V2. 
> JCasGen capability (optional) will create Java fields representing the Feature values; getters will become simple get operations.  Setters are more complex due to the need to support things like index corruption checking and journaling (when using Delta Cas operations).
> Types without JCasGen'd classes will use generic Java class representation and store their features in a couple of local collections.
> Mixing of these two approaches is also possible; e.g., the built-in type Annotation defines begin / end fields, which are represented as Java fields.  Additional features may be represented by subtypes having no JCasGen'd class definition, and those fields would be saved in the generic local collections. 
> The goal is to support fast/efficient access both with and without JCas-gen'd classes.
> Assign for each new Feature Structure created in a CAS, an incrementing ID, starting at 1. This id may be retrieved using a new FeatureStructure method get_id().  
> Name new internal fields and methods to start with an underscore to avoid collision with user-defined feature names, which cannot start with an underscore.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)