incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Spicar (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLEREZZA-686) LockableMGraphWrapper does not implement hashCode, equals and toString
Date Wed, 08 Feb 2012 09:56:59 GMT

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

Daniel Spicar commented on CLEREZZA-686:
----------------------------------------

I am not sure what the intention of this patch is. As I see it you are wrapping calls to Object.hashCode/Object.equals/Object.toString
into readLocks (i.e. you call super.hashcode). I assume what we really want, are delegation
to wrapped.hashCode etc., i.e. the hashCode method by the wrapped graph. Going there I see
the following issues:
- MGraph defines the interface for the equals method to be: "Returns true if other represents
the same mutable graph as this instance, false otherwise. It returns true if this == other
or if it s otherwise guaranteed that changes to one of the instances are immediately reflected
in the other." Given this description I think the current equals implementation is wrong,
we need to delegate the call to the wrapped Mgraph instance.
- From my understanding the read or write locks are only needed when reading from/writing
to the wrapped MGraph. Since we ware not doing it currently, I don't think the locks are needed
in this patch.
- However when we call the methods on the wrapped instance, then we may need them since we
do not know how they are implemented there. But technically we don't even know whether the
implementation there does write access to the graph (although I can't think of a reason why
it would do that).

I think in general we want to delegate the calls to the wrapped MGraph instance. Intuitively
I would put these calls in a readlock to be sure. Probably that will be fine. But from my
knowledge the contract of these methods does not restrict the MGraph Implementation to read
access only so theoretically there is a potential problem. But does it make sense to redefine
the contract of the MGraph interface for hashCode, toString, and equals to be read access
only? I'm not sure how this is handled elsewhere.
                
> LockableMGraphWrapper does not implement hashCode, equals and toString
> ----------------------------------------------------------------------
>
>                 Key: CLEREZZA-686
>                 URL: https://issues.apache.org/jira/browse/CLEREZZA-686
>             Project: Clerezza
>          Issue Type: Improvement
>          Components: rdf.core
>            Reporter: Rupert Westenthaler
>            Assignee: Daniel Spicar
>            Priority: Trivial
>         Attachments: CLEREZZA-686_rdf.core-LockableMGraphWrapper-hasCode-equals-toString.patch
>
>
> LockableMGraphWrapper does not implement hashCode, equals and toString. This is not a
big issue, because MGraphs are rarely used with sets or maps, but it is at least inconvenient
for logging and debugging.

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

        

Mime
View raw message