On 24/06/2021 01:25, Dan Smith wrote:
Under (2), I've violated the "single maintenance domain" assumption, but...
when I run with foo.jar and bar.jar on the class path, everything works just fine. I've
manually introduced an explicit dependency from foo.jar on bar.jar at compile time, which
seems like a stupid thing to do, but sealed classes don't seem any more problematic in
this regard than mutually recursive method signatures, etc.
As John noted, the JVM doesn't care about any of this and enforces its own
rules.
VM-wise, I tend to agree that this looks far less problematic.
Language-wise I was worried about checks for exhaustiveness - but then I
was reminded of the fact that a sealed hierarchy has a list of
"permits". So it's not like you can keep springing up new implementation
into existence - if A permits B and C, well, there are only two classes,
namely B and C, _somewhere_ in the classpath, with the usual
implications of using classpaths - e.g. that the order in which jars are
added to the classpath might affect what "B" and "C" truly are - but I
agree, nothing new under the sun here.
Where this might run into problems is in cases where the language infers
the permits list, which is something that was considered at one point.
Of course doing inference in a world where things are not compiled all
at the same time starts becoming problematic pretty quickly.
Maurizio
