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



Reply via email to