[
https://issues.apache.org/jira/browse/COMMONSRDF-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14516774#comment-14516774
]
Stian Soiland-Reyes commented on COMMONSRDF-7:
----------------------------------------------
I agree that immutability will have to be stated as some kind of equality and
hashCode stability, yes. There shouldn't be a requirement for all Commons RDF
methods to always return the same object reference -- just that a later call
should return an object that is .equal() to an earlier call. All RDFTerm and
Triple methods return either an immutable String or another immutable Commons
RDF object (plus the Optional<String> of Literal language which is also
immutable).
Thus an implementation of say Triple that decides to not keep the actual
subject/predicate/object instances in memory is free to reconstruct those
instances dynamically, as long as they are always equal to earlier instances
(hence immutable as far as Commons RDF is concerned).
If an implementation decides to add additional methods, then those are free to
be mutable as long as they don't affect the Commons RDF method values - for
instance I don't see anything wrong with an TripleImpl also having a
getStorageNode() method which return different backend nodes over time.
The only tricky side I can find is (perhaps this is a tangent for a new
BlankNode issue .. :/) BlankNode.ntriplesString() which is a bit loosely
defined now (e.g. not at all within BlankNode). By its contract there is
nothing saying that each BlankNode can't simply always return a hardcoded
"_:b1" - but for ntriplesString() to make sense for Triples in a Graph then it
should be unique within the graphs it is used (e.g. mutate or copy on insertion
to ensure ntriplesString() uniqueness). This is of course better achieved by it
somehow incorporating the uniqueReference() in the ntriplesString(), but I
don't think we want to have that as a strict requirement.
> Add immutability to the API for all RDFTerm and Triple instances
> -----------------------------------------------------------------
>
> Key: COMMONSRDF-7
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-7
> Project: Apache Commons RDF
> Issue Type: Improvement
> Reporter: Stian Soiland-Reyes (old)
> Labels: discussion, immutable
>
> 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)
