> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Dimanche 16 Décembre 2018 18:49:47 > Objet: Re: Flow scoping
>> On Dec 16, 2018, at 12:32 PM, Remi Forax < [ mailto:fo...@univ-mlv.fr | >> fo...@univ-mlv.fr ] > wrote: >> 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. > Yes, we actually prototyped this, and we have some opinions about it. But, the > question of shadowing (which this is really about — what happens when a > conditional variable with a non-contiguous scope shadows a field) seems > secondary (if we do flow scoping, we can go either way with shadowing > remediation, and if we don’t do flow scoping, it doesn’t matter.) So I’m going > to suggest that come back to this issue, and focus on the core scoping > questions for a bit…. Ok ! Rémi
