[
https://issues.apache.org/jira/browse/COMMONSRDF-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14516783#comment-14516783
]
Stian Soiland-Reyes commented on COMMONSRDF-7:
----------------------------------------------
If you read the API docs as-is, then there is nothing stopping an
implementation IRIImpl to have a setIRIString(String) method that mutates the
values returned from getIRIString(), ntriplesString() etc. Values could also
potentially be change under your feet with say a database backend. I think this
is what this issue proposes to block.
Is your suggestion that objects can only be mutable while they are not used
within a containing object? So an IRI can change until it is added to a Triple,
and a Triple can change until it is added to the Graph? This sounds a bit
trickier to formulate.. also it means if you find an IRI or Triple in the wild
you need to know if it is part of something to know if it is mutable or not -
what if you want to add it to your own Collection and need to rely on its
equality and hashing?
I think it could be simpler to just say that any RDFTerm and Triple are
immutable with respect to equality on the contract methods (including
hashCode()).
> 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)
