----- Mail original -----
> De: "John Rose" <john.r.r...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "Vicente Romero" <vicente.rom...@oracle.com>, "Brian Goetz"
> <brian.go...@oracle.com>, "Gavin Bierman"
> <gavin.bier...@oracle.com>, "amber-spec-experts"
> <amber-spec-experts@openjdk.java.net>, "joe darcy"
> <joe.da...@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, fo...@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
