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.

Reply via email to