Should Java Interfaces be Matchable?

Compiler version

3.2.0

Minimized example

It is a bit difficult to get a minimized example on this. An example of a specific commit fff0be9beb2c1edfabb9e385b72f12c21000f93f of banana-rdf, diesel branch. This was a commit to solve the answer to the problem @bishabosha came up with in issue 13416 and discussed on scala-users thread lib unification with match types. The answer worked for 2 out of 3 cases (wee below).

(btw. the pattern discussed in the thread seems so useful it seems to me, it should have a name. Perhaps it does?)

Output

Update: For a simplified version of the problem see the comment below

Having made the changes proposed by @bishabosha on that commit, two implementations worked well (Jena RDF and Tim Berners-Lee’s rdflib.js) but we had a problem with the Eclipse RDF4J implementation. My best explanation for the otherwise minor difference in code, is that Eclipse is built around interfaces whereas Jena is built on classes. And I guess Interfaces don’t implement Matchable by default.

Here is the type of error I was getting:

[error] -- [E038] Declaration Error: /Volumes/Dev/hjs/Programming/Scala3/CoSy/banana-rdf/scala3/rdf4j/src/main/scala/org/w3/banana/rdf4j/Rdf4j.scala:410:32
[error] 410 |         override protected def stringVal(uri: RDF.URI[R]): String =
[error]     |                                ^
[error]     |method stringVal has a different signature than the overridden declaration
[error]     |---------------------------------------------------------------------------
[error]     | Explanation (enabled by `-explain`)
[error]     |- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[error]     | There must be a non-final field or method with the name stringVal and the
[error]     | same parameter list in a super class of object URI to override it.
[error]     |
[error]     |   protected override def stringVal
[error]     |   (uri: org.eclipse.rdf4j.model.IRI & (org.eclipse.rdf4j.model.Value & (
[error]     |     org.eclipse.rdf4j.model.Value
[error]     |    & Matchable)) & (org.eclipse.rdf4j.model.IRI & (org.eclipse.rdf4j.model.Value
[error]     |
[error]     |   & Matchable))): String
[error]     |
[error]     | The super classes of object URI contain the following members
[error]     | named stringVal:
[error]     |   protected def stringVal
[error]     |   (uri: org.w3.banana.RDF.URI[org.w3.banana.rdf4j.Rdf4j.R]): String
[error]      ---------------------------------------------------------------------------
[error] Explanation
[error] ===========
[error] There must be a non-final field or method with the name stringVal and the
[error] same parameter list in a super class of object URI to override it.
[error]
[error]   protected override def stringVal
[error]   (uri: org.eclipse.rdf4j.model.IRI & (org.eclipse.rdf4j.model.Value & (
[error]     org.eclipse.rdf4j.model.Value
[error]    & Matchable)) & (org.eclipse.rdf4j.model.IRI & (org.eclipse.rdf4j.model.Value
[error]
[error]   & Matchable))): String
[error]
[error] The super classes of object URI contain the following members
[error] named stringVal:
[error]   protected def stringVal
[error]   (uri: org.w3.banana.RDF.URI[org.w3.banana.rdf4j.Rdf4j.R]): String

Expectation

It’s difficult to have an expectation here. Should Java interfaces be Matchable automatically?

If not then I’ll need to find a workaround. That is not so easy because all of rdf4j is built around interfaces, and they use factories to create objects that just return the interface. So one would need to change a lot there…

Is there a java interface for Matchable that I could add to the top of the hierarchy of rdf4j Node hierarchy to check if this is the problem?

I’ll try to see if I can find a minimal example code to duplicate the problem… But if you have any thoughts on the main question that would help.

[SethTisue]

We’re pursuing this on Discord, but regardless, I’m going to close this for now because

• I originally suggested opening the ticket here in the first place because of a hypothesis which has now proved incorrect • We haven’t yet been able to reproduce the problem on any computer except @bblfish’s

We can reopen the ticket (or make a new one, if it turns out the nature of the problem is entirely different than originally suspected) if or when new information comes to light.

[SethTisue]

note the -source future flag does not work with scala-cli

it does if you add -O, e.g. scala-cli compile -O -source:future . (or scala-cli compile -O -source -O future .), as per https://scala-cli.virtuslab.org/docs/commands/compile#scala-compiler-options