idea: URIs using opaque types and match types

[bblfish]

I thought it worth suggesting one way of building a URI library that has the following advantages:

1. it can abstract over multiple implementations
2. no efficiency loss (no extra object creations)
3. build on existing work
4. once existing one has implementations for existing URI libraries have been implemented it is possible to build one's own with new features such as interning discussed in Some requirements for a new URI class #6

I have used this concept for a very much larger library banana-rdf scala3 branch. The key interface is RDF which gives the main types for RDF, and then Ops which gives the key operations on each type, which are specified in the operations package.

These then get implemented for the various frameworks, such as Apache Jena or IBM Eclipse Rdf4J or even a JavaScript project such as Tim Berners-Lee's rdflib.js...

One can then write code independent of the implementation and switch between implementations by just changing the ops. (One can hard code that for a particular project to avoid the abstraction). For the abstract view see the test cases such as GraphTest.scala.

As I was writing some code to sign http headers, I actually started on this project for HTTP frameworks, abstracting between Akka and Http4s Messages. See httpSig's Http.scala with an Http4s implementation and an Akka implementation. I did not spend that much time on that as I was just trying to reduce duplication of code in tests and elsewhere.

The URI, URL and URN seem to be very similar to those use cases. Just as for RDF and HTTP all implementations build on the same standards, so that it is not surprising that there is a common abstraction.

One could thus start by implementing it for

• the current Http4s URI class (and add a URN class to it using |)
• lemonlabs URI scheme
• JS URI schems
• the Java URI scheme
• the various banana-rdf light weight versions of URIs...
• and indeed if a framework on which http4s bases itself has its own URI scheme, one could implement that, to avoid URI transformations...

and once tests are written to cover those, one can then write a pure scala implementation that can be confident it has captures the URI abstractions faithfully.