alternatives or complements to layers

[Brian Goetz]

Nice question, Peter.

I don't like the idea of automagically figuring it out based on 
overloads, but I do like the idea that there's a path to turning this 
bag of overloads into a coherent entity, so we can maximize investment 
in / compatibility with existing libraries.

The naive approach would have us look at a family of methods with the 
same name and whose parameters follow a certain pattern (i.e., there's a 
foo(Object) and a foo(P) for at least N primitive types P), and 
optimistically guessing that they must be manual specialization of the 
same semantics.  You can see why this makes us uncomfortable.

But, would it be possible to *say* this in the source code?  "Hey, 
specializer, these foo(X) methods for X=Object,int,long are the same 
method!"

This is closely related to one of the use cases called out in SotS, 
which is "hand-specialization of a specific instantiation of a generic 
method".  So if you have a method generic in any T:

<any T> void println(T t) { .. }

could you also add manually-written optimizations for known values of T?

// This is a specialization of a generic method substituting T=int
specialization void println(int i) { .. }

The question asked (not answered) in SotS is: can we do this for new 
code?  The follow-on question you are asking, I believe, is: can we 
compatibly convert existing families of methods to do this too?

> Ok, I buy that, but it would mean that existing core libraries would have to get a massive update.

Price of entry.  When we talk about how expensive this stuff is, this is 
part of the cost.  (Which, BTW, is probably the part that the community 
could most contribute to.)



On 1/7/2015 8:43 AM, Peter Levart wrote:
> Hi,
>
> While experimenting a bit with the current preliminary prototype, I
> found myself on several occasions wanting to call a method from "normal"
> API. Say System.out.println(x) with an x of type "any T". Usually a
> method that already has various overloads or a method taking an Object.
> Javac refuses:
>
>      method PrintStream.println(boolean) is not applicable
>        (argument mismatch; T cannot be converted to boolean)
>      method PrintStream.println(char) is not applicable
>        (argument mismatch; T cannot be converted to char)
>      method PrintStream.println(int) is not applicable
>        (argument mismatch; T cannot be converted to int)
>      method PrintStream.println(long) is not applicable
>        (argument mismatch; T cannot be converted to long)
>      method PrintStream.println(float) is not applicable
>        (argument mismatch; T cannot be converted to float)
>      method PrintStream.println(double) is not applicable
>        (argument mismatch; T cannot be converted to double)
>      method PrintStream.println(char[]) is not applicable
>        (argument mismatch; T cannot be converted to char[])
>      method PrintStream.println(String) is not applicable
>        (argument mismatch; T cannot be converted to String)
>      method PrintStream.println(Object) is not applicable
>        (argument mismatch; T cannot be converted to Object)
>    where T is a type-variable:
>      T extends <any> declared in method <T>test()
>
>
> But we know that whatever instantiation of T we choose, at least one of
> available overloaded methods would apply. If the set of overloaded
> methods contains one with parameter of type Object, then any
> instantiation of parameter of type "any T" would apply to at least one
> of those methods. At specialization time, the most appropriate method
> could be "selected".
>
> Of course this would not automatically route reference typed parameter
> to the most appropriate method among those taking various reference
> types - the one taking Object would always be chosen, but any value
> typed paremeter could select the most appropriate method (with implicit
> conversions and/or boxing).
>
> This could be viewed as a more natural complement to "layers" for
> supporting implementation by parts.
>
> The specializer would either have to inspect the target class somehow,
> or javac could provide the set of applicable methods in an attribute
> associated with invocation. Or perhaps, such invocation could be
> "specialized" as invokedynamic where the linking to the most appropriate
> method (with implicit conversions and/or boxing) would be choosen at 1st
> invocation.
>
> What do you think?
>
>
> Regards, Peter
>