permit with a class which is not a subtype is allowed
forax at univ-mlv.fr
forax at univ-mlv.fr
Tue Sep 3 15:25:50 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 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
More information about the amber-spec-experts
mailing list