In my latest (and probably 100th) lap around this
set of obstacles, I’ve used a workaround like the
following:
interface Something {
default someMethod(int x) { return x * Private.SOME_CON; }
/*should be private*/ static final class Private {
private Private() { }
private static final int SOME_CON = 42;
}
}
The private class can contain private nested classes,
private static methods, and private constants, all
inaccessible outside of the interface nest. A good use
of private nested classes would be classes which
provide one or more standard implementations
of the interface.
This pattern has the advantage of allowing a single-keyword
upgrade when private classes are eventually allowed, and also
a pretty small (though non-empty) API footprint today.
— John
> ----- Mail original -----
>> De: "John Rose" <[email protected]>
>> À: "Maurizio Cimadamore" <[email protected]>
>> Cc: "amber-spec-experts" <[email protected]>
>> Envoyé: Mercredi 18 Novembre 2020 09:07:18
>> Objet: Re: [statics] allowing static initializers in interfaces?
>
>> +1 from me too, and generally to heal the rift.
>> The inability to put private classes (and other “stuff”)
>> in an interface makes it hard to support canonical
>> algorithms in default methods, if they need auxiliary
>> types.
>
> yes,
> another example, in the patch introducing the new random generator API
> currently under review, there is this method
>
> default float nextFloat() {
> return (nextInt() >>> 8) * 0x1.0p-24f;
> }
>
> which a good example of why we also need private static final fields in
> interface.
>
> Rémi
>
