ASF subversion and git services commented on COMMONSRDF-42:

Commit 6e694fce7ee092a66c0b8599d3193567d1ad989b in incubator-commonsrdf's 
branch refs/heads/master from [~stain]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-commonsrdf.git;h=6e694fc ]

COMMONSRDF-42 Avoid generics in TripleLike

.. and almost avoid it in QuadLike

> Add GeneralizedTriple/Quad interfaces to api (and avoid TripleLike)?
> --------------------------------------------------------------------
>                 Key: COMMONSRDF-42
>                 URL: https://issues.apache.org/jira/browse/COMMONSRDF-42
>             Project: Apache Commons RDF
>          Issue Type: Wish
>          Components: api
>            Reporter: Peter Ansell
> Peter Ansell 
> [commented|https://github.com/apache/incubator-commonsrdf/pull/24#discussion_r82316729]
>  on COMMONSRDF-35:
> {quote}
> How about adding the following interfaces to Commons RDF API, rather than 
> experimenting inside of the integration modules that is unhelpful in the long 
> term for reuse of similar patterns. (Note that the appropriate generics type 
> declarations such as "T extends RDFTerm" have not been added to the 
> signatures below but they would be necessary in practice):
> * GeneralisedTriple<RDFTerm, RDFTerm, RDFTerm>
> * GeneralisedQuad<BlankNodeOrIRI, RDFTerm, RDFTerm, RDFTerm> implements 
> GeneralisedTriple<RDFTerm, RDFTerm, RDFTerm>
> * Triple implements GeneralisedTriple<BlankNodeOrIRI, IRI, RDFTerm>
> * Quad implements Triple, GeneralisedQuad<BlankNodeOrIRI, BlankNodeOrIRI, 
> IRI, RDFTerm>
> * GeneralisedGraph<GeneralisedTriple, RDFTerm, RDFTerm, RDFTerm> (need the 
> copied generic types for methods that don't just accept GeneralisedTriple)
> * GeneralisedDataset<GeneralisedQuad, BlankNodeOrIRI, RDFTerm, RDFTerm, 
> RDFTerm>
> * Graph implements GeneralisedGraph<Triple, BlankNodeOrIRI, IRI, RDFTerm>
> * Dataset implements GeneralisedDataset<Quad, BlankNodeOrIRI, BlankNodeOrIRI, 
> IRI, RDFTerm>
> The key is that the commonly reused interfaces Triple/Quad/Graph/Dataset now 
> do not have the confusing "Like" suffix, and they have no generics arguments 
> to remove an extra barrier to reuse. All implementations of Triple will be 
> specialised subsets of GeneralisedTriple, so it doesn't seem to be an issue 
> to uptake to represent the APIs this way.
> Inheriting Quad from Triple and other similar instances isn't a design issue 
> IMO, as correct code should be written to check instanceof Quad before it 
> checks instanceof Triple if the user wants to preserve the dataset reference.
> Even though Quad is not defined in terms of RDF-1.1, there will be no simple 
> way to integrate with RDF4J without some version of it. It is also a commonly 
> used term in the community, even if it didn't make it into the RDF-1.1 
> specification so it doesn't introduce new issues for understandability.
> Implementing a Triple-level integration for RDF4J would not be a useful 
> pursuit IMO given the background of the RDF4J Statement interface always 
> having had a getContext method. I would prefer if this integration went just 
> for Quad<->Statement translation in its initial versions to get it completed 
> sooner rather than later.
> {quote}

This message was sent by Atlassian JIRA

Reply via email to