> De: "Brian Goetz" <brian.go...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts@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
