[
https://issues.apache.org/jira/browse/OAK-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253514#comment-13253514
]
Jukka Zitting edited comment on OAK-65 at 4/13/12 4:34 PM:
-----------------------------------------------------------
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 it suggests
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}
was (Author: jukkaz):
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
