Sealed types

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Dimanche 9 Décembre 2018 16:13:12
> Objet: Re: Sealed types

> I thought about Remi’s argument a little more:

>>> basically forcing me to write the code that the compiler generates for me when i
>>> use an anonymous class.

> And, it illustrates the danger of permitting syntactic shorthands out of
> convenience — the user will not only not understand that the shorthand is
> merely a convenience, but will develop a sense of entitlement in it, and wonder
> why it won’t work everywhere.

> Sealed types are SUMs; a sum should declare what it is a sum of. If we just had
> the explicit syntax:

> sum X = { A, B, C };

> No one would be too bent out of shape that a sum can’t (directly) contain an
> anonymous class or lambda, because OBVIOUSLY a sum has to name its parts. But,
> because of two quirks of syntax, Remi (and millions of others, I’m sure) now
> think I’m being gratuitously mean.

> Quirk 1 is attaching the sum to the superclass being declared. This is natural,
> in that we’re explicitly declaring it as a sum. Quirk 2 is the shorthand form,
> where we are willing to infer the subtypes when it is “obvious”, because we
> want to be nice. (Shame that our reward for being nice is that people think
> we’re mean.)

> If we think this is a problem, perhaps we should drop the short-form of
> “permits” (though I think that would merely make people think we’re mean in
> another way.) Or choose a short form that doesn’t seem to play into
> all-too-easy misconceptions of what the feature is for. (Certainly, because we
> can’t even come up with too good a short form right now, we should probably
> leave it out for now, until we find something that doesn’t require three drinks
> to seem sensible.)

> At root, though, this disagreement over restrictions is really a disagreement
> over what sealed types are. I want to say they are sums; Remi wants to say they
> are really just access control lists for class extension. I think the sum
> interpretation is more powerful and more grounded, so I lean that way.

We want to introduce sum types in Java. 
So we have to find a syntax, a runtime representation and it has to work well with the current features of Java. 

We can introduce them as sealed interface (note: interface not type), that one solution, in that case, because this feature has to be integrated with the rest of Java, i think we have to support anonymous class and lambda (given that if we delay the full support of this feature by the VM, the support of lambdas has to be delayed too because the lambda proxy class is only known at runtime). 

Another solution is to introduce a "real" sum type, in that case the runtime implementation do not have to use an interface, the sum type can be a new kind of class (sum class) supported by the VM and we can come with a syntax close to what we see in other existing languages that define sum types. 
sum X { 
A(int x, int y) | B(String s) { ... } | AnotherSumType | AnInterface | AClass | AnEnum | ARecord 
} 
In that case, you can not "implements" a sum type and the type defined inside as to have at least the same visibility as the sum type. 
The main issues with this solution is that it requires to introduce a new kind of type in the VM (if not erased) and it's harder to retrofit an existing hierarchy to be a sum type. 

So either we go with an interface and in that can i think we should support all ways to implement an interface or we go with a sum class and in that case i agree that we do not need to support anonymous classes. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20181209/c5169715/attachment-0001.html>