Compile-time type hierarchy information in pattern switch

forax at univ-mlv.fr forax at univ-mlv.fr
Thu Apr 5 15:40:59 UTC 2018


----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "mark" <mark at io7m.com>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 5 Avril 2018 17:25:36
> Objet: Re: Compile-time type hierarchy information in pattern switch

> Yes, this is surely an option.
> 
> But it doesn't answer the underlying question -- if the hierarchy
> changes in various ways between compile and runtime, what behavior can
> the user count on, and what changes yield "undefined" behavior?

no, it's not undefined, at least not an "undefined behavior" as in C.
At runtime, the code executed will be the one compiled. A hierarchy changes is not a backward compatible changes, so one can expect surprise and not something undefined.

> 
> While its easy to say "you should do what the code says", taking that
> too far ties tie our hands behind our back, and makes switches that
> should be O(1) into O(n).

???, not sure to understand.
If we record which case was executed for a given class in a hashmap and use it as a cache, it will be always O(1) for all subsequent calls with the same class.

Rémi 

> 
> On 4/5/2018 11:21 AM, Remi Forax wrote:
>> Or we can not try to do any check at runtime that validate the view of the world
>> at compile time.
>> Currently, there is no check that verifies that the catch are in the right order
>> or that a cascade of if-instanceofs means the same thing at compile time and at
>> runtime.
>>
>> My opinion, we should just run the code that was compiled, even if the world as
> > changed between the compilation and the execution.


More information about the amber-spec-experts mailing list