Yeah, I mean as a generic asFoo() type method, particularly in an interface. I also suggest having generic bounds to suggest what types are possible. It really depends on if the casting is useful to a user of the library or a developer of the library.
On 14 September 2016 at 22:23, Stian Soiland-Reyes <st...@apache.org> wrote: > You mean to add unwrap() to the implementation classes? So it would just do > a cast? But we have an operator for that in Java... :-) > > If you mean to add it to RDFTermFactory as a different name/style for the > many asSomething() methods, perhaps just as the name as()? > > That is how Jena does it, to hide instanceof and casting: > > https://jena.apache.org/documentation/javadoc/jena/ > org/apache/jena/rdf/model/RDFNode.html#as-java.lang.Class- > > Btw, the "factory" methods might both wrap or unwrap, e.g. > JenaRdfTermFactory.asJenaNode(rdfterm) would unwrap a JenaRDFTerm > implementation directly, but still recognise a "foreign" RDFTerm which is > instead wrapped/converted to a new JenaNode instance. > > I'm still worried by an API that takes "any" class, it is not too useful if > you don't know what classes are actually supported, as you see Jena > therefore also added canAs() in addition to more specific asLiteral() and > asResource(). > > Perhaps Andy Seaborne have views on those kind of convenience methods? They > could be added to the RDFTerm interface with a default implementation that > just tries to cast. > > On 13 Sep 2016 2:00 a.m., "Matt Sicker" <boa...@gmail.com> wrote: > > Couldn't you do the JDBC Wrapper style interface and have a generic method > like: > > <T> T unwrap(Class<T> cls); > > Or make more specific unwrap methods like: > > <T extends Statement> T unwrap(Class<T> cls); > > If this is for implementation-specific casts and such. > > On 12 September 2016 at 19:56, Stian Soiland-Reyes <st...@apache.org> > wrote: > > > [[ Cross-post - prefer replies to dev@commons ]] > > > > Each of the Common RDF implementations come with a RDFTermFatory > > > > http://stain.github.io/incubator-commonsrdf/integration/org/apache/ > > commons/rdf/api/RDFTermFactory.html > > > > On a classical flat classloader the implementations of this factory > > can be discovered with java.util.ServiceLoader > > > > > > So if you have say a JsonLdRDFTermFactory you can call .createTriple() > > etc - and it would be backed by that implementation. As mentioned the > > marker interfaces will allow you to later on get hold of the wrapped > > object, e.g. to do some RDFS reasoning on a Jena Model or to parse it > > to a serializer. > > > > > > But what if you already have a 'native' object, e.g. a > > org.eclipse.rdf4j.model.Statement - and you want to convert it/adapt > > it to the corresponding Commons RDF API Triple? > > > > Obviously there would not be a general interface for this (without > > using ?-generics) as each backend implementation would have different > > (so far unrelated) types - but we can at least agree on the common > > style? > > > > In > > > > http://stain.github.io/incubator-commonsrdf/integration/org/apache/ > > commons/rdf/rdf4j/RDF4JTermFactory.html > > > > I suggests as*() adapter methods like: > > > > > > RDF4JQuad asQuad(org.eclipse.rdf4j.model.Statement > > > > RDF4JTriple asTriple(org.eclipse.rdf4j.model.Statement statement) > > > > RDF4JTerm asRDFTerm(org.eclipse.rdf4j.model.Value value) > > > > RDF4JDataset asRDFTermDataset(org.eclipse.rdf4j.repository.Repository > > repository) > > > > RDF4JGraph asRDFTermGraph(org.eclipse.rdf4j.model.Model model) > > > > RDF4JGraph asRDFTermGraph(org.eclipse.rdf4j.repository.Repository > > repository) > > > > > > but also the inverse converters: > > > > org.eclipse.rdf4j.model.Value asValue(RDFTerm term) > > > > org.eclipse.rdf4j.model.Statement > > asStatement(TripleLike<BlankNodeOrIRI,IRI,RDFTerm> tripleLike) > > > > > > (These will unpack the wrapped value if it's an RDF4JTerm - or create > > a new RDF4J native instance if it's a "foreign" class) > > > > > > Questions: > > > > > > a) Do these adapter methods belong in the RDFTermFactory or should > > there be a new family of 'adaptor factories'? (e.g. the Jena Factory > > > > > > b) What should we call these methods? Is as*() appropriate or should > > they more closely match the createTriple() etc methods from > > RDFTermFactory? > > > > With asSomething() I wanted to hint of adaptation - rather than > > 'convert' or 'create' - but without having to commit to adaptation > > with adapt() or wrap(). > > > > > > Now sometimes the implementations use the same class name as Commons > > RDF (e.g. Quad or Graph). Code-wise this is not too hard to deal with > > (avoid importing either), but it means it can get more confusing for > > downstream API users who do auto-complete and then don't know what > > direction they are adapting. > > > > > > c) Should the adapter methods have short names (e.g. asGraph()) - > > distinguished by type polymorphism and javadocs - or more verbose to > > show which particular return-type you get? (e.g. asJenaGraph() and > > asCommonsRDFGraph()) ) > > > > > > d) Do we need to rename RDFTermFactory to RDFFactory (or just RDF) ? > > > > > > > > -- > > Stian Soiland-Reyes > > http://orcid.org/0000-0001-9842-9718 > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > -- > Matt Sicker <boa...@gmail.com> > -- Matt Sicker <boa...@gmail.com>
