[sealed] Use 'open' instead of 'non-sealed'?
brian.goetz at oracle.com
Tue Jan 26 14:23:27 UTC 2021
> 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.
More information about the amber-spec-experts