[
https://issues.apache.org/jira/browse/COMMONSRDF-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15611905#comment-15611905
]
ASF GitHub Bot commented on COMMONSRDF-7:
-----------------------------------------
Github user ajs6f commented on the issue:
https://github.com/apache/incubator-commonsrdf/pull/26
Generally, looks good to me. The questions I have are:
1. Do we need to talk about `equals` and `hasCode` separately?
2. Can we clarify the definition of "immutable" a bit: most people, I
think, would assume that it means that e.g. `Quad::getSubject` is actually
going to return the identical object, not an `equals` object. I'm not against
the definition you are using here, and I can understand how it might give a
useful flexibility during implementation, but it might be nice to have a
higher-level note explaining it carefully.
3. I think there could be a use of `default` methods here.
> Document that RDFTerm, Triple and Quad are immutable
> ----------------------------------------------------
>
> Key: COMMONSRDF-7
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-7
> Project: Apache Commons RDF
> Issue Type: Improvement
> Components: api
> Reporter: Stian Soiland-Reyes (old)
> Assignee: Stian Soiland-Reyes
> Labels: discussion, immutable
> Fix For: 0.3.0
>
>
> From https://github.com/commons-rdf/commons-rdf/issues/57
> ansell:
> {quote}
> As mentioned in #45, should we add a contract requirement that all RDFTerm
> instances (and Triple?) be implemented as immutable objects?
> https://github.com/commons-rdf/commons-rdf/issues/45
> {quote}
> stain:
> {quote}
> +1, if we say SHOULD. But only the exposed RDFTerm++ methods need to be
> immutable - so this should probably go into each of their descriptions. So if
> I have a getDatabaseThingie() method that can be mutable.
> {quote}
> ansell:
> {quote}
> The value of stating that the objects must be immutable is decreased if it
> only applies to the results of the API methods. A useful goal would be to
> ensure that the entire object is immutable to give a guarantee about
> threadsafety, but that may be too much for all implementations to support.
> Just stating that the results of the visible API methods are immutable
> doesn't help much. It is also not likely to apply to the methods that return
> Optional, as to enable serialisation, the actual field may not be an Optional
> itself in most cases.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
