Sorry about the double threads - I messed up and thought the original post
didn't go through.

Looking further into this it seems in Java generics are largely a compile
time thing. The generic type information is wiped out from the type on
compile. So how does Java know which overload to call when the only
difference in the generic type of the parameter?

The answer is - it doesn't.

I whipped up a quick bit of Java to test this :



public static String Onk(ArrayList<String> str) {
    System.out.println("string");
    return "";
}

public static int Onk(ArrayList<Integer> it) {
    System.out.println("int");
    return 0;
}



This fails to compile :


Error:(11, 24) java: name clash:
Onk(java.util.ArrayList<java.lang.Integer>) and
Onk(java.util.ArrayList<java.lang.String>) have the same erasure




This sort of thing doesn't seem to be a problem for Scala, so it must be
doing something funky under the hood to resolve these methods.


Now, I can get the generic information about these methods using reflection
:

(->> Dist$/MODULE$ type .getMethods vec (map #(.getGenericParameterTypes
%))  pprint)

gives me :

([#<ParameterizedTypeImpl
scala.collection.Seq<scala.Tuple2<java.lang.Object,
com.cra.figaro.language.Element<T>>>>,
  #<ParameterizedTypeImpl com.cra.figaro.language.Name<T>>,
  com.cra.figaro.language.ElementCollection]
 [#<ParameterizedTypeImpl
scala.collection.Seq<scala.Tuple2<com.cra.figaro.language.Element<java.lang.Object>,
com.cra.figaro.language.Element<T>>>>,
  #<ParameterizedTypeImpl com.cra.figaro.language.Name<T>>,
  com.cra.figaro.language.ElementCollection]


So in theory I think I should be able to hack something together to resolve
to the correct method. It won't be fast - or elegant, but hopefully it can
work.


Thanks




On Fri, Jun 26, 2015 at 3:38 AM Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:

> That was meant as a response to the other thread.
>
> On Fri, Jun 26, 2015 at 10:35 AM, Ambrose Bonnaire-Sergeant <
> abonnaireserge...@gmail.com> wrote:
>
>> They apparently differ in the return type. I don't think
>> clojure.lang.Reflector considers the return type hint
>> when resolving methods.
>>
>> Thanks,
>> Ambrose
>>
>> On Fri, Jun 26, 2015 at 4:16 AM, Stephen Wakely <
>> fungus.humun...@gmail.com> wrote:
>>
>>> javap gives :
>>>
>>>  public <T> com.cra.figaro.language.AtomicDist<T>
>>> apply(scala.collection.Seq<scala.Tuple2<java.lang.Object,
>>> com.cra.figaro.language.Element<T>>>, com.cra.figaro.language.Name<T>,
>>> com.cra.figaro.language.ElementCollection);
>>>
>>>   public <T> com.cra.figaro.language.CompoundDist<T>
>>> apply(scala.collection.Seq<scala.Tuple2<com.cra.figaro.language.Element<java.lang.Object>,
>>> com.cra.figaro.language.Element<T>>>, com.cra.figaro.language.Name<T>,
>>> com.cra.figaro.language.ElementCollection);
>>>
>>>
>>> Bit of an eyesore, but the two methods only differ in the generic types..
>>>
>>> On Thu, Jun 25, 2015 at 9:11 PM Stephen Wakely <
>>> fungus.humun...@gmail.com> wrote:
>>>
>>>>
>>>> So using reflection on the objects gives the following signatures -
>>>> they have identical signatures :
>>>>
>>>> {:name apply,
>>>>     :return-type com.cra.figaro.language.CompoundDist,
>>>>     :declaring-class com.cra.figaro.language.Dist$,
>>>>     :parameter-types
>>>>     [scala.collection.Seq
>>>>      com.cra.figaro.language.Name
>>>>      com.cra.figaro.language.ElementCollection],
>>>>     :exception-types [],
>>>>     :flags #{:public}}
>>>>    {:name apply,
>>>>     :return-type com.cra.figaro.language.AtomicDist,
>>>>     :declaring-class com.cra.figaro.language.Dist$,
>>>>     :parameter-types
>>>>     [scala.collection.Seq
>>>>      com.cra.figaro.language.Name
>>>>      com.cra.figaro.language.ElementCollection],
>>>>     :exception-types [],
>>>>     :flags #{:public}}
>>>>
>>>>
>>>> On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra <
>>>> the.stuart.sie...@gmail.com> wrote:
>>>>
>>>>> Scala has to compile down to JVM bytecode just like Clojure, but it
>>>>> may change method signatures along the way.
>>>>>
>>>>> You could try running `javap` to disassemble the compiled Scala
>>>>> bytecode and figure out what the method signatures actually are. Or use
>>>>> Java reflection to examine the objects you have and see what methods they
>>>>> declare.
>>>>>
>>>>> –S
>>>>>
>>>>>
>>>>>
>>>>> On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote:
>>>>>>
>>>>>> I am trying to call into some Scala that has the following overloaded
>>>>>> methods :
>>>>>>
>>>>>>   def apply[T](clauses: (Double, Element[T])*)(implicit name:
>>>>>> Name[T], collection: ElementCollection) =
>>>>>>     new AtomicDist(name, clauses.toList, collection)
>>>>>>
>>>>>>   def apply[T](clauses: (Element[Double], Element[T])*)(implicit
>>>>>> name: Name[T], collection: ElementCollection) =
>>>>>>     new CompoundDist(name, clauses.toList, collection)
>>>>>>
>>>>>> So one method takes a list of tuples of Double to Element and the
>>>>>> other method takes a list of tuples of Element to Element.
>>>>>>
>>>>>> I am using t6.from-scala (https://github.com/t6/from-scala) to build
>>>>>> up my list of Tuples. But when building these up there is no way to 
>>>>>> specify
>>>>>> explicit type information about the collections. Consequently when 
>>>>>> calling
>>>>>> this apply method Clojure will always choose to call the first method -
>>>>>> even when my list is a collection of Element to Element tuples.
>>>>>>
>>>>>> I can definitely appreciate how it is going to be tricky for Clojure
>>>>>> to determine the correct overload to use here. Is there any way I can
>>>>>> somehow force it to call the correct overload myself?
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Stephen
>>>>>>
>>>>>>
>>>>>>
>>>>>>  --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Clojure" group.
>>>>> To post to this group, send email to clojure@googlegroups.com
>>>>> Note that posts from new members are moderated - please be patient
>>>>> with your first post.
>>>>> To unsubscribe from this group, send email to
>>>>> clojure+unsubscr...@googlegroups.com
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/clojure?hl=en
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Clojure" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to clojure+unsubscr...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to