----- Mail original -----
> De: "Brian Goetz" <brian.go...@oracle.com>
> À: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
> Envoyé: Mardi 11 Décembre 2018 21:08:38
> Objet: Flow scoping
> (Note to observers: we did an internal survey so I could gauge the
> comfort level of the EG with the flow scoping rules for pattern binding
> variables. We'll do a public survey at some point in the future.)
>
> Thanks for taking the time to take the quiz. The results were pretty
> good. For the early examples, which were mostly about if-then and
> short-circuiting booleans, people got the "right" answer (the answer the
> current rules, at
> http://cr.openjdk.java.net/~briangoetz/amber/pattern-semantics.html,
> gives):
>
> if (x instanceof String v) {
> // x in scope here
> }
> else {
> // x not in scope here
> }
>
> Note that we say "not in scope", not just "not DA". There are a number
> of reasons for choosing this seemingly more complicated approach.
at the same time, not introducing a variable in the scope avoid tricky use
cases like
class A {
Object a;
void m(Object o)
if (o instanceof A a) {
System.out.println(a); // o at runtime
} else {
System.out.println(a); // this.a at runtime
}
}
}
so in my opinion, neither 'not being in scope' nor 'not being DA' are good
strategies because as you said below we want to be able to have name reuse in
switch or if ... else.
I think the best is to introduce the notion of poison variable, a variable that
you can reuse but that is introduced in the scope, i.e. so your have the best
of the two options.
> (These have been discussed here before; I'm mostly summarizing.) One
> reason is the scoping for traditional "switch" gets in the way:
>
> switch (x) {
> case String v: ...; break;
> case Integer v: ...; break;
> case Long v: ...; break;
> }
>
> Since the body of a switch is one big scope, when we get to the second
> case, `v` would already be in scope, and have type `String`. Similarly,
> in an if-else block that represents the same computation:
>
> if (x instanceof String v) { ... }
> else if (x instanceof Integer v) { ... }
> else if (x instanceof Long v) { ... }
>
> (Note too, that it is an important design constraint that the rules
> allow the above two to be freely refactored into each other.)
[...]
Rémi
