Updated State of the Specialization

[Ali Ebrahimi]

I don't think this is workaround, maybe anti-workaround!
If you want bypass java's generic type system, just don't use it.
Foo foo = new Foo<String>();
foo.bar("Test");
foo.bar((Object)"Test");


On Sun, Dec 21, 2014 at 1:48 AM, Timo Kinnunen <timo.kinnunen at gmail.com>
wrote:

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