I want to fully understand what is going on before doing anything.
Interestingly if I convert the Java code below to Scala it fails to compile
with the same error :
def Onk(str: util.ArrayList[String]): String = {
println("String")
"erk"
}
def Onk(it: util.ArrayList[Integer]): Integer = {
println("Int")
0
}
But changing it to using (I think) more idiomatic Scala compiles and runs
fine.
def Onk(str: (String)*): String = {
println("String")
"erk"
}
def Onk(it: (Integer)*): Integer = {
println("Int")
0
}
On Fri, Jun 26, 2015 at 12:27 PM Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:
> 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.
>
--
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.
