[
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)
