[jira] [Commented] (OAK-65) Naming of NodeState and related classes

["Jukka Zitting (Commented) (JIRA)" <ji...@apache.org>]

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

Jukka Zitting commented on OAK-65:
----------------------------------

We discussed naming as a part of the [earlier thread|http://markmail.org/message/vrhizcykjhbfisjg] on the internal tree model. The {{{...Data}}} naming pattern was already [brought up|http://markmail.org/message/qqjfwjrf3beavwya], but was [considered troublesome|http://markmail.org/message/fjvau6snc5gxu5ms] since they suggest dumb data objects with getters and setters.

Here's my [comment|http://markmail.org/message/zi4axxdsgzfjjsbt] that ultimately led to the current {{{...State}}} naming pattern:

{quote}
I think the best alternatives here are the ones we're
already using in jr2: PropertyState, NodeState and ChildNodeEntry.
Like Dominique, I tend to associate ...Data names with dumb bean
objects, whereas ...State has the nice suggestion of "this is a
specific (immutable) state of an item, a different state will be
represented by another state instance". Unfortunately jr2 treats
...State more like "this is the current state of an item, updated
automatically on changes", which might be a bit confusing for jr3.
{quote}
                
> 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