On Thu, 24 Mar 2022 18:58:43 GMT, Joe Darcy wrote:
>> Small refactoring to use sealed classes in the MethodHandle implementation
>> hierarchy.
>>
>> DelegatingMethodHandle is non-sealed rather than sealed since it has two
>> subclasses, one defined as a nested class and only a separate type
> Small refactoring to use sealed classes in the MethodHandle implementation
> hierarchy.
>
> DelegatingMethodHandle is non-sealed rather than sealed since it has two
> subclasses, one defined as a nested class and only a separate type in the
> same package. The permits clause does not allow
On 22/03/2022 4:56 pm, Rémi Forax wrote:
On Tue, 22 Mar 2022 04:38:15 GMT, ExE Boss wrote:
javac should be changed to allow fully qualified access to private inner
classes in the permits clause of an enclosing class.
This is not how private works, private means accessible between the '{'
On Sun, 20 Mar 2022 21:31:15 GMT, Joe Darcy wrote:
> Small refactoring to use sealed classes in the MethodHandle implementation
> hierarchy.
>
> DelegatingMethodHandle is non-sealed rather than sealed since it has two
> subclasses, one defined as a nested class and only a separate type in the
On Tue, 22 Mar 2022 04:38:15 GMT, ExE Boss wrote:
> javac should be changed to allow fully qualified access to private inner
> classes in the permits clause of an enclosing class.
This is not how private works, private means accessible between the '{' and the
'}' of the class.
The permits
On Sun, 20 Mar 2022 21:31:15 GMT, Joe Darcy wrote:
> Small refactoring to use sealed classes in the MethodHandle implementation
> hierarchy.
>
> DelegatingMethodHandle is non-sealed rather than sealed since it has two
> subclasses, one defined as a nested class and only a separate type in the
On Mon, 21 Mar 2022 18:17:06 GMT, Mandy Chung wrote:
> > $ javac com/acme/*.java
> > is fine. Am I missing something?
>
> If you make P.Q private, it will fail the compilation.
>
Yes, I got that part. I did make a comment earlier ("Two of those subclasses
are nested "private" in another
On Mon, 21 Mar 2022 06:08:32 GMT, Athijegannathan Sundararajan
wrote:
> $ javac com/acme/*.java
>
> is fine. Am I missing something?
If you make P.Q private, it will fail the compilation.
To make `DelegatingMethodHandle` a sealed class, we could make
`AsVarargsCollector` and `WrappedMember`
On Sun, 20 Mar 2022 21:31:15 GMT, Joe Darcy wrote:
> Small refactoring to use sealed classes in the MethodHandle implementation
> hierarchy.
>
> DelegatingMethodHandle is non-sealed rather than sealed since it has two
> subclasses, one defined as a nested class and only a separate type in the
On Sun, 20 Mar 2022 21:31:15 GMT, Joe Darcy wrote:
> Small refactoring to use sealed classes in the MethodHandle implementation
> hierarchy.
>
> DelegatingMethodHandle is non-sealed rather than sealed since it has two
> subclasses, one defined as a nested class and only a separate type in the
On Mon, 21 Mar 2022 04:04:45 GMT, Athijegannathan Sundararajan
wrote:
> "DelegatingMethodHandle is non-sealed rather than sealed since it has two
> subclasses, one defined as a nested class and only a separate type in the
> same package. The permits clause does not allow listed those two
On Sun, 20 Mar 2022 21:31:15 GMT, Joe Darcy wrote:
> Small refactoring to use sealed classes in the MethodHandle implementation
> hierarchy.
>
> DelegatingMethodHandle is non-sealed rather than sealed since it has two
> subclasses, one defined as a nested class and only a separate type in the
Small refactoring to use sealed classes in the MethodHandle implementation
hierarchy.
DelegatingMethodHandle is non-sealed rather than sealed since it has two
subclasses, one defined as a nested class and only a separate type in the same
package. The permits clause does not allow listed those
13 matches
Mail list logo
