You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commonsrdf.apache.org by "Andy Seaborne (JIRA)" <ji...@apache.org> on 2015/04/16 19:41:58 UTC

[jira] [Comment Edited] (COMMONSRDF-7) Add immutability to the API for all RDFTerm and Triple instances

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

Andy Seaborne edited comment on COMMONSRDF-7 at 4/16/15 5:40 PM:
-----------------------------------------------------------------

Can we define this by contratct?

It really means .hashcode and .equals are stable. Value-based equality objects must be stable for .equals and hashcode on the fields needed for the equality contract else Java hash maps are unstable.  A graph is a set of triples which places restrictions on triples and hence RDF terms.

In general (java) the fields can change if .hashcode/.equals are stale but ours come down to Java strings so are not mutable.

As for any internal fields, they are caches, and if they keep out the way, it does not matter.  If they don't keep out of the way, the commonsrdf-api contracts can't be met.


was (Author: andy.seaborne):
CAn we define this by contratc?

It really means .hashcode and .equals are stable. Value-based equality objects must be stable for .equals and hashcode on the fields needed for the equality contract else Java hash maps are unstable.  A graph is a set of triples which places restrictions on triples and hence RDF terms.

In general (java) the fields can change if .hashcode/.equals are stale but ours come down to Java strings so are not mutable.

As for any internal fields, they are caches, and if they keep out the way, it does not matter.  If they don't keep out of the way, the commonsapi contracts can't be met.

> 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)