----- Mail original -----
> De: "Brian Goetz" <[email protected]>
> À: "Remi Forax" <[email protected]>
> Cc: "Maurizio Cimadamore" <[email protected]>,
> "amber-spec-experts" <[email protected]>
> 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, [email protected] wrote:
>>
>> ----- Mail original -----
>>> De: "Maurizio Cimadamore" <[email protected]>
>>> À: "Remi Forax" <[email protected]>, "amber-dev"
>>> <[email protected]>
>>> 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
