Feedback on Sealed Types

[Alan Malloy]

Yes, that is what I suggest. Two points, though.

First, the sugar benefit is at least a tiny bit larger than you say. You
also get to omit instances of <T,U> if the interface is parameterized, as I
expect it will often be. I argue you should get to omit public, too: the
implementations of a sum should always be public, just as the accessors for
a record should be, for the same reason: they are the entire propose of
defining the type, and allowing variation here detracts from their semantic
value.

And second, I don't know that counting the number of saved
characters/tokens is the best way to measure the benefits anyway. An
enhanced for loop over an array is not that much shorter than an old-style
for loop with an explicit index - in fact it probably saves fewer
characters than a couple "implements FooSum". But it's clearly a win
because it communicates intent better, and leaves fewer opportunities to
make a mistake, either in writing the code or in reading it. Likewise the
ability to say in a single token, "this is a closed sum" has legibility
benefits aside from just being shorter.

On Wed, May 1, 2019, 6:58 AM Brian Goetz <brian.goetz at oracle.com> wrote:

>
>
>
> I kind a like the intellectual separation between
> - a sealed interface which represent a closed type and requires a permit
> clause and
> - an enum interface which represent a sum type which is sugar on top of
> sealed interface + records.
>
>
>
> To be clear, I think what Alan is suggesting, and what Remi is supporting,
> is:
>
>  - Make “sealed” the primitive for defining closed types, as originally
> proposed, and also
>  - Make the following
>
> enumerated interface Foo {
>     R(X), S(Y);
>
>     STUFF
> }
>
> sugar for
>
> sealed interface Foo
>     permits R, S {
>
>     STUFF
>
>     record R(X) implements Foo { }
>     record S(Y) implements Foo { }
> }
>
> Is that correct?
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190501/e0e1c81b/attachment.html>