On Tue, Mar 31, 2015 at 2:55 AM, Peter Ansell <[email protected]> wrote:
> On 31 March 2015 at 05:49, Gary Gregory <[email protected]> wrote: > > I was surprised to see an interace called IRI. When I see IRI, I expect a > > class like the JRE's URI (or URL), not an interface. > > > > This interface looks more like a IRIProvider to me. > > If it was implemented as a class, then every implementation would need > to extend it to make it suit their system, or we create it as a final > class and hope it suits everyone, which doesn't work. > I wasn't proposing it should be final. > > It is not within our scope to dictate the internal workings of the > systems we are trying to provide interoperability for. In particular, > libraries written in non-Java-JVM languages will have different > assumptions to the Java based implementations. Although they mostly > provide interoperability with Java, the interfaces should be > applicable to them in the same way as the Java libraries. If the > entire API is written using interfaces, they have less Java-specific > details to work around. > Could you explain this is more detail or show a simple scenario where having interfaces makes things easier for such an implementations? Keep in mind that such an implementation also has to deal with other IRI implementations which would then have to be replaced with their own versions, so things might actually get more complicated as implementations have to handle two cases. I see a clear increase of complexity on the other side: with the interfaces just having a constant value of type IRI (as in classes generated by something like schemagen) requires either implementing the interface or have a runtime dependency on the RdfTermFactory. Cheers, Reto
