[
https://issues.apache.org/jira/browse/OAK-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253735#comment-13253735
]
Jukka Zitting commented on OAK-65:
----------------------------------
I'm not too tied to the naming, and as mentioned, the {{...State}} names do
come with quite a bit of baggage from jr2. Just pointing out that this was
already discussed and a rough consensus was reached (though in the context of
the MK). Anyway, I think we can and should revisit naming as part of a broader
Oak API design discussion (like the one Angela and you were already starting).
> Naming of NodeState and related classes
> ---------------------------------------
>
> Key: OAK-65
> URL: https://issues.apache.org/jira/browse/OAK-65
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, mk
> Reporter: Michael Dürig
>
> As discussed here [1] we should rethink the nameing of the NodeState and
> related classes.
> I suggest the following renaming:
> NodeState -> NodeData
> PropertyState -> PropertyData
> TransientNodeState -> NodeState
> KernelNodeState -> KernelNodeData
> My reasoning: the current NodeState and PropertyState classes are immutable
> (and thus
> represent pure values i.e. data). The word state implies mutability
> (after all OOP is about mutation of state all over) so renaming
> TransientNodeState to NodeState should make sense. Also the oak API will
> be more publicly visible than the lower level MK API. So having catchy
> names there is a plus.
> http://markmail.org/thread/xi5dgjljduc7y7eq
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
