permit with a class which is not a subtype is allowed

[forax at univ-mlv.fr]

----- 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 16:49:25
> Objet: Re: permit with a class which is not a subtype is allowed

> (moving thread to amber-spec-experts, as this is a design question)
> 
> There’s two coupled features here, language and VM.
> 
> It is unquestionably the case that a PermittedSubtypes attribute should be
> allowed to not only name classes that are not subtypes, but in fact do not
> exist, are not accessible to the supertype, etc.  Otherwise, it would simply be
> too brittle.  The hint is in the name — *permitted* subtypes.  These classes
> are permitted, not required, to be my subtype.
> 
> As to the language, basically all the choices (check, don’t check, warn) are
> viable, and its a tradeoff of catching possible bugs vs being excessively
> demanding on the user.  Before we even address the question of “must J be a
> subtype”, we first have to ask: how much work should the compiler do to find J
> in the first place?  Should it be permissible to say “permits
> ClassThatDoesNotCurrentlyExist”?  Or “permits
> ClassThatExistsButIsInaccessibleToMe”?
> 
> There’s arguments for and against.  If we want to type check the hierarchy in
> this manner, it means that all the permitted subtypes be co-compiled (even if
> they are in other compilation units, or even other packages) or their class
> files be present when compiling.  The “farther away” the other class is, the
> more intrusive this restriction is.  Where we settled is that classes in the
> permits clause must be in the same module, and if it is the unnamed module must
> be the same package, in part because that is our best approximation for groups
> of classes that are co-compiled.  But even this can be burdensome.
> 
> A related issue is that this is a new kind of restriction — where class A
> imposes a restriction on some other class B in another compilation unit.  We
> should probably have a better reason than “I don’t see the point of allowing
> this” before proceeding.
> 
> 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.

Do you have examples of such design ?

Rémi

> 
>> On Sep 3, 2019, at 9:31 AM, forax at univ-mlv.fr wrote:
>> 
>> ----- Mail original -----
>>> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
>>> À: "Remi Forax" <forax at univ-mlv.fr>, "amber-dev" <amber-dev at openjdk.java.net>
>>> Envoyé: Mardi 3 Septembre 2019 15:19:33
>>> Objet: Re: permit with a class which is not a subtype is allowed
>> 
>>> I think there might be a range of options here - error is one, lint
>>> warning (e.g. redundant permits) is another.
>> 
>> I don't see the point of being able to specify a type which is not a subtype
>> given that it will never checked by the VM
>> the VM only check when you load a class that if the parent as a an attribute
>> PermittedSubtypes then the class is among the permitted subtypes.
>> 
>> In my opinion, the attribute "PermittedSubtypes" should only store direct
>> subtypes and it should be enforced by the compiler.
>> 
>> otherwise you can write some fun stuff like
>>  sealed interface I permits J { }
>>  sealed interface J permits I { }
>> 
>> note that I and J are not related in term of hierarchy.
>> 
>>> 
>>> But, nevertheless you raise a valid point.
>>> 
>>> Maurizio
>> 
>> Rémi
>> 
>>> 
>>> On 03/09/2019 14:03, Remi Forax wrote:
>>>> The compiler allows to permit a class which is not a subtype.
>>>> 
>>>> public class AncestorPermitExample {
>>>>   sealed interface I permits A {
>>>>   	
>>>>   }
>>>>   final static class A {
>>>>   	
>>>>   }
>>>> }
>>>> 
>>>> The VM too but it's not a bug for the VM (i believe).
>>>> 
> >>> Rémi