[
https://issues.apache.org/jira/browse/CLEREZZA-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203513#comment-13203513
]
Daniel Spicar commented on CLEREZZA-686:
----------------------------------------
About locking:
I'm just thinking in terms of interface contract here. Current MGraphs do not
need locks (and I can't think of any currently that would need it ever) but I
don't know the future. There is nothing that disallows an Mgraph to read (or
even write, even though that sound silly) in the toString/hashCode/ewuals
methods. The options I see:
- Ignore the problem, it might never occur
- Document it as an interface contract somewhere - where? With the current type
system it may be necessary in the MGraph interface because we just wrap generic
MGraphs with LockableMGraphWrapper in TcProviderMultiplexer.
- Restrict what can be wrapped by LockableMGraphWrapper by introducing some
other type requirements.
Just looking for some consensus on this issue.
> 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
