Have you considered writing a wrapper method in Scala and calling that?
Thanks,
Ambrose
On Fri, Jun 26, 2015 at 7:24 PM, Stephen Wakely <fungus.humun...@gmail.com>
wrote:
> 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.
>
--
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.
