Sealed types -- updated proposal

[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é: Jeudi 17 Janvier 2019 17:50:36
> Objet: Re: Sealed types -- updated proposal

>> Allowing public auxillary subtype of a primary sealed type is the sweet spot for
>> me, better than trying to introduce either a nesting which is not exactly
>> nesting or a rule than only works for pattern matching.

> It was not my intent to propose something that “only works for pattern matching”
> (I presume you’re thinking about the treatment of enums in switch, and carrying
> that over more or less directly.) I was suggesting something a little broader;
> if you have a sealed type X, and you import X, you would automatically get
> X.{A..Z} statically imported where A..Z are subtypes. This gives you the enum
> behavior, but more broadly; you can say “new A”, etc. (We can consider
> extending this to enums as well, since enums and sealed types have such close
> affinity.) This is still less intrusive than public aux types.

> But, even adopting the “enum” behavior might well be good enough, has precedent,
> and is surely simpler; the place where nesting would bite the most is in
> switches, and this would provide relief.

> Further, I suspect that the “public aux subtypes of primary sealed type” will be
> received by the audience more as “glass half empty”; rather than being happy
> about the new situations where they could use aux types, they’ll be annoyed at
> where they can’t, or frustrated with the complexity of the rule. Finally, the
> arguments against using aux types (findability) have some merit. So I was
> looking for something less sharp-edged.

>> I don't understand how "semi-final" can be a good keyword, the name is too
>> vague. Given that the proposal introduce the notion of sealed types, "sealed"
>> is a better keyword.

> There’s two sides here. The connection to finality is powerful, and I like that.
> On the other hand, semi-final might sound nonsensical (like “half pregnant”) to
> some, and silly (because of the pun) to others. So I’l accept that this is
> likely to strike some people as “too clever” and cause more than its share of
> unnecessary whining.

> Contextual keywords are usually OK as modifiers (as long as they don’t want to
> show up somewhere else), so `sealed` is not terrible.

???, i'm confused, 
a contextual keyword means it's only a keyword in some context, so if it shows up somewhere else, it's not a keyword. 

That's said, i think we should have a strategy (like with '_') to gradually promote contextual keywords to be real keywords (maybe apart the ones in the module-info). 
If a contextual keyword is introduced in release N, the compiler should also emit a warning for all identifiers with the same name. 
in release N + K, the compiler can now emit an error instead of a warning. 

> In earlier discussions, there was some concern about sealed vs final (Kevin),
> especially with regard to negation. I thought about this some more and I think
> we can say:

> - A subtype of a sealed type is implicitly sealed.
> - If that subtype is a concrete class without a permits clause, then it is
> effectively final, though not actually final. (You can say final explicitly if
> you want the belt-and-suspenders.)
> - You can un-do the inheritance of sealing with “non-sealed”, whether the
> subtype is a class or interface, abstract or concrete. So no non-sealed vs
> non-final confusion.

>> For un-sealing a subtype, "unsealed" seems to be a good keyword.

> If the keyword is `sealed`, then I strongly prefer its opposite be `non-sealed`.
> (Among other reasons, I don’t want to open the door to having different
> inversions for different modifiers.)

non-<the keyword for sealed> is good for me. 

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