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 = {
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
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 generic
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
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.
>
> Than
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
wrote:
> javap gives :
>
> public com.cra.figaro.language.AtomicDist
> apply(scala.collection.
javap gives :
public com.cra.figaro.language.AtomicDist
apply(scala.collection.Seq>>, com.cra.figaro.language.Name,
com.cra.figaro.language.ElementCollection);
public com.cra.figaro.language.CompoundDist
apply(scala.collection.Seq,
com.cra.figaro.language.Element>>, com.cra.figaro.language.N
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.
I am sadly quite clueless when it comes to Java.
De-compiling the Scala class file to Java gives me the following:
public AtomicDist apply(Seq>> clauses,
Name name, ElementCollection collection) {
return new AtomicDist(name, clauses.toList(), collection);
}
public Compou
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
Do you know how to call this method from Java 1.4? That will probably give
enough context to use in Clojure type hints.
Thanks,
Ambrose
On Thu, Jun 25, 2015 at 9:03 PM, Stephen Wakely
wrote:
> Interesting. That could be a good last resort.
>
> On Thu, Jun 25, 2015 at 1:27 PM Andy Fingerhut
> w
Interesting. That could be a good last resort.
On Thu, Jun 25, 2015 at 1:27 PM Andy Fingerhut
wrote:
> Sorry, I do not know whether Clojure can or cannot determine the correct
> overload in this situation.
>
> All I have is a weak suggestion that work well enough: have you considered
> creating
Sorry, I do not know whether Clojure can or cannot determine the correct
overload in this situation.
All I have is a weak suggestion that work well enough: have you considered
creating wrapper functions, e.g. in Scala or Java, that have different
enough function signatures that Clojure can easily
12 matches
Mail list logo
