[sealed] Use 'open' instead of 'non-sealed'?

[Brian Goetz]

> The 'non-sealed' keyword looks not very java-ish.

There was a method to this madness.  The goal is to *make* it Java-ish, 
by adopting this convention uniformly whenever we need the opposite of 
something.  So when we need non-static, non-final, non-abstract, etc, 
these are ready and waiting for us, and each reinforces the others.  It 
is the first one that bears the slings and arrows.

Consider the opposite of `final`, which we went through a bikeshed-paint 
on, but in the end didn't need immediately.  The "obvious" opposite of 
final for a field might be "mutable", but that's a terrible modifier for 
a class or methods.  Similarly, an opposite of final for classes or 
methods might be "open".  But you see how this leads to an irregular 
taxonomy, where the opposite of X isn't even consistent across places 
where X can be used.  This is actually what led us to the non- prefix, 
even though sealed was the first place to get it.

You could also think of this as a meta-bikeshed-budget-management move; 
without it, every keyword needs its own bikeshed to determine its 
opposite.  And, knowing the community, every choice we make ("mutable") 
will have a half-life of complaints over something ultra-trivial -- only 
to be repeated on the next one.  By picking a scheme that can be applied 
consistently, we avoid all that.

So while "open" may be locally better (and I don't disagree), I think it 
is globally worse.

As a minor note, `open` means something already in the context of a 
module descriptor -- "open to deep reflection".  (ANd in fact, we can 
imagine that we may very well need this concept in the language.)


> It adds cognitive
> load, especially to non-native speakers, as it includes the negation
> inside. Also, it complicates tooling implementation (in particular,
> lexing Java programs). Probably some of us want to move forward the
> hyphenated keywords proposal and need a guinea pig to experiment with,
> but this doesn't seem enough reason to justify its use.
>
> I suggest using the 'open' contextual keyword instead. The 'open'
> class/interface means that it can be inherited without any
> restriction. 'open', 'sealed', and 'final' keywords are mutually
> exclusive. Any class/interface is either 'open', or 'sealed', or
> 'final', no other option. The classes that don't directly
> extend/implement sealed classes/interfaces are implicitly 'open'
> (though it's possible to redundantly specify the 'open' keyword). The
> classes that extend/implement sealed class/interface must specify
> open/sealed/final explicitly.
>
> What do you think?
>
> With best regards,
> Tagir Valeev.