[
https://issues.apache.org/jira/browse/COMMONSRDF-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14490926#comment-14490926
]
Peter Ansell commented on COMMONSRDF-11:
----------------------------------------
I would suggest that if there needs to be a simple base implementation that
some contributors here want to reuse and extend that it be implemented outside
of the core API project. In that project, any binary compatibility issues would
be managed and implemented separately to enable those users to decide on the
level of binary compatibility that they require. Even if none of the big
implementations adopt that implementation as a basis, it would probably still
want to internally agree on the binary compatibility that it would provide
across its versions.
However, we require a test harness implementation here to give us a case to
discuss issues within, without having to worry about reuse of any of the
specific parts of the test harness by third-party users. The discussions about
the simple module are interrupting our focus on the API module, even though its
status as a pure test harness module has been discussed throughout the life of
the project so far.
If necessary to clearly articulate its role, we could rename the
commons-rdf-simple module to commons-rdf-tester to emphasise its role along
with its performance (none) and stability guarantees, and plan to reestablish a
separate base or abstract implementation separately at a later date once the
base API is released and the API/tester modules exit the incubator. That module
could then also explore threadsafe implementations, which as Stian says are
outside of the scope of the base API contract. Any threadsafe implementations
should be able to be implemented within the contracts that we give in the base
API, even if we don't mention threadsafety, which leads to the assumption of
non-threadsafe by default unless known otherwise.
However, as Sergio proposed, we could still benefit from versioning the test
harness using patch versions (0.1.x), and versioning the API module solely
using major and minor versions (0.1).
> Simple should be extendable classes
> -----------------------------------
>
> Key: COMMONSRDF-11
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-11
> Project: Apache Commons RDF
> Issue Type: Improvement
> Reporter: Stian Soiland-Reyes
> Assignee: Stian Soiland-Reyes
>
> In my view, org.apache.commons.rdf.simple should also be a possible basis for
> other implementations - for instance if they only need a new Graph and Triple
> implementation, they should be able to use the other classes directly.
> Current the simple classes are defined like:
> {code}
> final class LiteralImpl implements Literal {
> {code}
> with a mixture of public and package constructors.
> I would prefer for these to all be public, non-final, so that it would be
> easy to extend the simple* classes if so desired, and to instantiate them
> directly without having to make a shadow of SimpleRDFTermFactory.
> (Note - SimpleRDFTermFactory is not final and so can easily be subclassed to
> reuse some of the implementations, but constructors must be at least
> protected to be subclassable outside this package)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
