Re: Updated State of the Specialization

[Timo Kinnunen]

The workaround works if you do it like this:


class Foo<T>{

void bar(String s){ System.out.println(1); }

void bar(T s){ System.out.println(2); }


public static void main(String... args) {

Foo<String> foo = new Foo<String>();

((Foo<?>) foo).bar("Test");

((Foo)foo).bar((Object)"Test");

}

} 


(Yes, it’s a dirty workaround…)





Hope this helps.





-- 
Have a nice day,
Timo.

Sent from Windows Mail





From: Ali Ebrahimi
Sent: ‎Saturday‎, ‎December‎ ‎20‎, ‎2014 ‎23‎:‎05
To: Timo Kinnunen, Brian Goetz
Cc: valhalla-dev at openjdk.java.net







Ah I forget to say, your proposed workaround is not compatible with current java generics. consider following example:

class Foo<T>{
     void bar(String s){}
     void bar(T s){}

} 



Foo<String> foo = new Foo<String>();


foo.bar((String)"Test"); //fails to compile
foo.bar((Object)"Test");//fails to compile
foo.bar("Test");//fails to compile





Is this a bug or feature? echoing Brain.........







On Sat, Dec 20, 2014 at 11:52 PM, Timo Kinnunen <timo.kinnunen at gmail.com> wrote:




I’m not proposing any particular translation scheme, I’ll leave that to more capable people :) Obviously there has to be one, but I’m coming to this from point of view of how an end-user would be interacting with and using that translation scheme from their code.









-- 
Have a nice day,
Timo.

Sent from Windows Mail





From: Ali Ebrahimi
Sent: ‎Saturday‎, ‎December‎ ‎20‎, ‎2014 ‎19‎:‎36


To: Timo Kinnunen
Cc: valhalla-dev at openjdk.java.net








what is your translation scheme for specialization? is that Brian's Or ...

I'm confused, from your response T instantiated as “valuable” int not int? I'm correct?



On Sat, Dec 20, 2014 at 9:41 PM, Timo Kinnunen <timo.kinnunen at gmail.com> wrote:




It is int, so you end up with two methods in the API which both take the same type and a need to distinguish between them somehow. 




This is analogous to the BigList<BigInteger> example from the previous email. There the problem was about choosing between one method taking a normal BigInteger and another taking an “erasable” BigInteger.




Here the problem is about choosing between one method taking a plain int and another method taking a “valuable” int.









-- 
Have a nice day,
Timo.

Sent from Windows Mail





From: Ali Ebrahimi
Sent: ‎Saturday‎, ‎December‎ ‎20‎, ‎2014 ‎19‎:‎04
To: Timo Kinnunen
Cc: valhalla-dev at openjdk.java.net







What is instantiated type var for T in List<int>? Integer or int




On Sat, Dec 20, 2014 at 3:54 PM, Timo Kinnunen <timo.kinnunen at gmail.com> wrote:




Here an anyfied List version and a demo:




interface List<any T> { 
public void remove(int position);
public void remove(T element);





static void test(List<int> list) {




// calls remove(int position);


list.remove((int) 3);




// calls remove(T element);
list.remove(3);

}

}




The choice of which method to prefer with the plain, cast-less version is somewhat arbitrary. My rationale for preferring it like this rather than the other way around is that the specialized type is more interesting. Thus the compiler should make calling methods taking one as easy as possible.

-- 
Have a nice day,
Timo.

Sent from Windows Mail





From: Ali Ebrahimi
Sent: ‎Saturday‎, ‎December‎ ‎20‎, ‎2014 ‎0‎:‎53
To: Timo Kinnunen
Cc: Brian Goetz, valhalla-dev at openjdk.java.net







As long as I know, we currently have List<E> and We try to specialize (or any-fy) that.
How your solution handle List<int> case?





On Sat, Dec 20, 2014 at 2:15 AM, Timo Kinnunen <timo.kinnunen at gmail.com> wrote:
Hi,


I’m not sure Peeling is necessary. The reason is that the problem it’s trying to solve already exists in the current Java and it has workarounds too. Here’s a demonstration with three ListLike<T> adaptations and the workarounds:


interface SmallList<T> {

public void remove(short position);

public void remove(T element);

}

interface MediumList<T> {

public void remove(int position);

public void remove(T element);

}

interface BigList<T> {

public void remove(BigInteger position);

public void remove(T element);

}


public class Workaround {

@SuppressWarnings({ "rawtypes", "unchecked" })

static void method(SmallList<Short> smallList, MediumList<Integer> mediumList, BigList<BigInteger> bigList) {


smallList.remove((short) 3);

smallList.remove((Short) (short) 3);


mediumList.remove(3);

mediumList.remove((Integer) 3);


((BigList<?>) bigList).remove(BigInteger.valueOf(3));

((BigList) bigList).remove((Object) BigInteger.valueOf(3));

}

}


For the record, none of the workarounds feel “correct” to me, although the int/Integer pair gets close.


Rather than Peeling, what I think is needed is to streamline overload selection so that the specialized methods are selected whenever possible and the non-specialized methods can be manually selected with extra casts, like this:



smallList.remove((short) 3);

smallList.remove(3);




mediumList.remove((int) 3);

mediumList.remove(3);




bigList.remove((BigInteger) BigInteger.valueOf(3));

bigList.remove(BigInteger.valueOf(3));




--
Have a nice day,
Timo.

Sent from Windows Mail





From: Brian Goetz
Sent: ‎Friday‎, ‎December‎ ‎19‎, ‎2014 ‎22‎:‎31
To: valhalla-dev at openjdk.java.net







I've updated the State of the Specialization here:
   http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html

The old version is here:
   http://cr.openjdk.java.net/~briangoetz/valhalla/specialization-1.html