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