Updated State of the Specialization

[Ali Ebrahimi]

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 <ali.ebrahimi1781 at gmail.com>
> *Sent:* ‎Saturday‎, ‎December‎ ‎20‎, ‎2014 ‎19‎:‎36
>
> *To:* Timo Kinnunen <timo.kinnunen at gmail.com>
> *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 <ali.ebrahimi1781 at gmail.com>
>> *Sent:* ‎Saturday‎, ‎December‎ ‎20‎, ‎2014 ‎19‎:‎04
>> *To:* Timo Kinnunen <timo.kinnunen at gmail.com>
>> *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 <ali.ebrahimi1781 at gmail.com>
>>> *Sent:* ‎Saturday‎, ‎December‎ ‎20‎, ‎2014 ‎0‎:‎53
>>> *To:* Timo Kinnunen <timo.kinnunen at gmail.com>
>>> *Cc:* Brian Goetz <brian.goetz at oracle.com>,
>>> 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
>>>>
>>>
>>
>