In your other email I guess you are referring to anonymous classes
implementing a sealed interface, right? E.g.
sealed interface Foo {
void m();
/* static final */ Foo f1 = new Foo() { ... }
/* static final */ Foo f2 = () -> {};
}
Right. We already restrict anon and lambda in
Good catch! I fully support the restriction.
In your other email I guess you are referring to anonymous classes
implementing a sealed interface, right? E.g.
sealed interface Foo {
void m();
/* static final */ Foo f1 = new Foo() { ... }
/* static final */ Foo f2 = () -> {};
}
Tha
I agree, PermittedSubtypes should only contain stable names :)
Rémi
- Mail original -
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Mercredi 9 Octobre 2019 23:35:48
> Objet: Re: [sealed] Sealed local classes?
>> Proposal: ban `sealed` and `non-sealed` modifiers on _local_ cla
I agree, PermittedSubtypes should only contains stable names.
Rémi
- Mail original -
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Mercredi 9 Octobre 2019 23:26:26
> Objet: [sealed] Sealed local classes?
> It is allowable, though somewhat silly, to put the `final` modifier on
- Mail original -
> De: "Brian Goetz"
> À: "amber-spec-experts"
> Envoyé: Mercredi 9 Octobre 2019 23:10:40
> Objet: [records] Native members
> Jon has pointed out that it is possible to declare a record with native
> methods and/or constructor.
>
> Let's just add `native` to the set of
Proposal: ban `sealed` and `non-sealed` modifiers on _local_ classes
and interfaces.
And we would want to extend the ban we have for the other two forms of
"subclasses inside implementations", lambdas and inner classes, to local
classes.
It is allowable, though somewhat silly, to put the `final` modifier on
local classes.
From a hierarchy-protection point of view, allowing local classes to be
`sealed` is also silly, as it cannot be extended from outside the method
anyway, and even if it could, such types can't show up in APIs
Jon has pointed out that it is possible to declare a record with native
methods and/or constructor.
Let's just add `native` to the set of modifiers that are not allowed on
members of records
You are not wrong. In fact, I had the very same thought ( and the
implementation does similar ), but we want to leave room here for
deconstructors/extractors. With the wording in the current draft, it will be
possible to switch the implementation without the need to update the
specification
- Mail original -
> De: "Remi Forax"
> À: "Brian Goetz"
> Cc: "amber-spec-experts"
> Envoyé: Mercredi 9 Octobre 2019 18:44:23
> Objet: Re: Record Component attributes
> - Mail original -
>> De: "Brian Goetz"
>> À: "Remi Forax" , "amber-spec-experts"
>>
>> Envoyé: Mercredi 9
- Mail original -
> De: "Brian Goetz"
> À: "Remi Forax" , "amber-spec-experts"
>
> Envoyé: Mercredi 9 Octobre 2019 17:59:56
> Objet: Re: Record Component attributes
>> just to be sure, do we agree that a record component can be deprecated,
>> synthetic, have a generic signature, have un
just to be sure, do we agree that a record component can be deprecated,
synthetic, have a generic signature, have unknown attributes, have annotation
and type annotations ?
Deprecated: not clear what this would mean, since removing a component
is not a BC or SC change, and therefore remova
Hi all,
just to be sure, do we agree that a record component can be deprecated,
synthetic, have a generic signature, have unknown attributes, have annotation
and type annotations ?
so the attributes with a special meaning are
SIGNATURE, DEPRECATED, SYNTHETIC, RUNTIME_VISIBLE_ANNOTATIONS,
RUNT
13 matches
Mail list logo
