getPermittedSubclasses() on j.l.rClass returning an array of ClassDesc

forax at univ-mlv.fr forax at univ-mlv.fr
Mon Oct 26 11:04:40 UTC 2020


----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Vicente Romero" <vicente.romero at oracle.com>, "Brian Goetz" <brian.goetz at oracle.com>, "Gavin Bierman"
> <gavin.bierman at oracle.com>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>, "joe darcy"
> <joe.darcy at oracle.com>
> Envoyé: Lundi 26 Octobre 2020 04:54:12
> Objet: Re: getPermittedSubclasses() on j.l.rClass returning an array of ClassDesc

> On Oct 24, 2020, at 3:32 PM, forax at univ-mlv.fr wrote:
>> 
>> the 'get' was removed because the method was not returning Class objects, now
>> that permittedSubclasses behave like the other methods of java.lang.Class,
>> the name should be changed back to "get..." to reflect that.
> 
> One reason (beyond good old consistency) to use the old
> name with the old type:  If we ever upgrade the return types
> from array to List<…>, we’ll want to use new method names.
> Using more than one naming convention for these methods
> reduces options for choosing a successor naming convention.

I believe it's better to introduce a new interface in between Collection and List, let say Array and refactor Object[]/int[]/... to implement Array.

> 
> (Assuming we don’t have overload selection on return
> types, which I view as a very tempting idea but one that
> has yet to show a killer use case.)

It's OT but there are several reasons for using the return type in the overload selection are
- the inference is using the return type but not when overloading, many students find this weird
  (as they find weird to have contravariance of generics using wildcards but not contravariance of method parameter types when overriding)

- plain old ad-hoc polymorphism
  class Defaults {
    static int empty() { return 0; }
    static double empty() { return 0.0; }
    ...
    static <T> T empty() { return null; }
  }

- be able to express covariant bridges in Java

I do not think there is a killer use case in this list anyway.

regards,
Rémi


More information about the amber-spec-observers mailing list