nest syntax proposal

[forax at univ-mlv.fr]

I've slept on that problem this night. 

Let's focus first on the sealed type, You are proposing to declare the subtypes inside the sealed type, so you get nesting automatically and you can use import + a special switch rules to be able to reference a subtype directly. 
I believe this fell flat with a sealed class, because you are mixing inheritance and enclosing scopes. 

Let's take an example 
sealed class Expr { 
public void aMethod() { ... } 

record Value(int value) extends Expr; 
record Add(Expr left, Expr right) { 
public void anotherMethod() { 
aMethod(); // call super.aMethod() or Expr.this.aMethod() ? 
} 
} 
} 

as you can see, we are mixing inheritance and enclosing scope here, i don't think it's wise to let a user to write this kind of monstrosity. 

I wish inner classes where never invented (anonymous class are fine) but it's a too late ... 

We can say that records are always a static class, but refactoring a class to a record or vice-versa will create instant puzzler. 
We can only support sealed interface, not sealed class, it may be not a bad idea per itself, anyway i think we should no try to mix nesting and subtyping. 

Rémi 

> 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é: Lundi 21 Janvier 2019 00:07:01
> Objet: Re: nest syntax proposal

>>> And they understand auxiliary classes. Let’s work with the familiar concepts.

>> but your solution seems tailored to sealed types, what if i have several record
>> classes with no common abstract type, how it works ?
>> and again there is no refactoring between a classical interface and a sealed
>> interface, something we should try offer.

> Indeed, I think there are two things here. We can choose to address one or both
> or neither, with the obvious tradeoffs.

> Issue #1 is that sealed types naturally form a family, you’re going to switch
> over them, etc, like enums, and we want the same (or more) nice treatment as we
> currently get with enums in switch. So it makes sense to define them all in one
> place; indeed, that should be the common case. Doing something with import
> helps here, but as you say, it is more specific to sealed types. On the other
> hand, enums and sealed types are related, so mirroring the special treatment
> that enums get (maybe even giving both a little more) is a low-energy-state
> solution.

> Issue #2 is that with records, one line per file starts to seem silly. This has
> a lot of overlap with #1, but not entirely. You could argue its a more general
> solution, and maybe we like that, but maybe we don’t. It surely is more
> intrusive — affecting the existing semantics of auxiliary classes, and
> dramatically increasing the use of auxiliary classes (which, BTW, we’ve banned
> from the JDK source base because they make life very hard for build tooling),
> etc. It’s a bigger hammer.

> Its also possible we do nothing here, and let users nest the subtypes and
> clients just say “import static SealedType.*”. That’s the least intrusive, so
> we should compare cost/benefit against that baseline.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190126/c1fba85b/attachment.html>