permit with a class which is not a subtype is allowed
forax at univ-mlv.fr
forax at univ-mlv.fr
Tue Sep 3 16:06:30 UTC 2019
----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 3 Septembre 2019 17:41:38
> Objet: Re: permit with a class which is not a subtype is allowed
>>> My preference would be for this to be a warning, not an error.
>> Conceptually, i've a hard time to think that i want simultaneously a closed
>> hierarchy and let the subtype open by specifying only it's name that may exist
>> or not or that may not visible.PermittedSubtypes then the class is among the
>> permitted subtypes.
> You're making an argument that "I can't think of a case where we would
> want that." Which is a fine starting point -- it means its not
> immediately unreasonable to ask the question "should we outlaw it".
> But there's a big leap from "I can't think of any reason to not outlaw
> it" to "so we must outlaw it", so let's not prematurely take this leap.
nope, i can not see a reasonable use case, hence i'm openly asking if someone has one.
> As I said before, there is a tradeoff here, which is between catching
> more errors at compile time (good) and imposing more constraints on how
> users compile their code (not so good) also possibly constraints on how
> code is migrated (also, not so good.)
The problem of offering tradeoff like this one is that you are diminishing the value of having permit clauses.
I'm sure people will complain that Java should not have introduced permit clauses because it's not really enforced by the compiler, it's a mere warning.
And you have the second effect which is, if the permit clause raise a warning when the class doesn't exist, it logically also means that the case clause of a switch on type also raises a warning when the class doesn't exist.
More information about the amber-spec-observers