There has been an indirect reply here: https://github.com/commons-rdf/commons-rdf/issues/43, as the issue point to this thread I though to add a back-link but I would prefer to have a discussion here and to discuss about concrete code proposals
According to Sergio the proposal is "a wrapper implementation instead of commons interface". As the proposal doesn't contain any wrapper, this might refer to the question on when to define classes and when to define interfaces. The API proposal has the following interfaces and classes (without .events) Interfaces: - BlankNodeOrIri.java <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/BlankNodeOrIri.java> - Graph.java <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/Graph.java> - ImmutableGraph.java <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/ImmutableGraph.java> - RdfTerm.java <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/RdfTerm.java> - Triple.java <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/Triple.java> - Literal.java <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/Literal.java> Classes: - Language.java <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/Language.java> - Iri.java <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/Iri.java> - BlankNode.java <http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/src/main/java/org/apache/commons/rdf/BlankNode.java> The reason why Language and Iri are classes rather than interfaces is because the additional work for service providers exposing the API to implement the interfaces themselves seems to outweigh the benefits of the possibility to provide an own implementation without inheriting the overhead of an additional String per instance (the classes are not final, so implementation can still provide an Iri implementation that stores all the lengthy IRIs on disk, in this case there is just an empty and unused string field for the JIT to optimize away). The reason why BlankNode is a class and not an interface is to discourage polymorphism. If an instance is more than just a BNode user will be more likely to expect to get the very same instance back, but as described in the Readme there is no such guarantee. Typically implementations will replace BlankNode objects with instances of their own subclass of BlankNode as soon as they can (i.e. as soon as originally added instance becomes eligible for garbage collection). Cheers, Reto On Tue, Jan 13, 2015 at 7:30 AM, Reto Gmür <r...@apache.org> wrote: > Hi all, > > I've just committed a new version to > > http://svn.apache.org/viewvc/commons/sandbox/rdf/trunk/ > > The most obvious change if that instead of having TripleCollection, MGraph > and Graph there is now Graph and ImmutableGraph. With this change the usage > of the term "graph" is a bit closer to the colloquial usage (at the price > of being a bit more distant to the usage in the specs). > > I've also added some questions and answers to the Readme highlighting the > points where the API offers advantages compared with other APIs and API > proposals. > > The API goes beyond the most minimalistic API by allowing for graph > listeners to be notified when a graph is changed. This is a popular feature > that cannot easily be added on top of the core API so it is included. > > I've added the getLock method to the main Graph interface. API notes > describe how implementation can easily provide such a lock and what to do > in situation where no such lock is needed. In clerezza we have been using a > subinterface LockableMGraph to provide this feature. Experience has shown > however that this approach makes it unnecessary difficult to write generic > code, for example generic methods processing a Graph often had to check the > type and downcast to do the locking on graphs than can be locked. > > > Please let me know about what you think about this proposal. > > Cheers, > Reto > >
