Flow scoping

forax at univ-mlv.fr forax at univ-mlv.fr
Sun Dec 16 18:00:17 UTC 2018


> 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é: Dimanche 16 Décembre 2018 18:49:47
> Objet: Re: Flow scoping

>> On Dec 16, 2018, at 12:32 PM, Remi Forax < [ mailto:forax at univ-mlv.fr |
>> forax at 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20181216/799fdfd6/attachment.html>


More information about the amber-spec-experts mailing list