I agree with you that matching exactly the java method signatures
would be less confusing. I was advocating this to be as transparent
as possible with interop. I was in minority :)
Reviewing what I said, case 1b is a bit more complex, the compiler cannot
decide between the two methods case (byte and thread signatures).
We are not talking about primitive number types here, byte is as alien to
the Thread object as a fish is to roller blades.
As for 1a, it looks like interop is attempting also to demote to a byte if a
method
can possibly match. I find this odd. From the top of my head, only integers and
longs
where to be folded into this single case, it seems that bytes and shorts are
also
concerned.
As for case 2, objects like Long and Integer are unboxed when searching for a
signature. If the signature has int or long (the primitive types) it will match.
Should be the same for Short and Byte classes. This mimics Java.
I suspect interop to search signatures based on the size of the value from
the smallest (byte) to the biggest (long).
The int signature is found first in your test because the value fits in an int.
Just curious, define also a byte signature for the same method in that class.
I feel it would match with a value less than 255.
My two cents, be specific when calling a Java method and cast the operators
to avoid ambiguity. I am concerned by the exception that may
occur if you feed a value in excess of what the primitive type supports
in your method. The runtime may or may not find a matching method
depending on the value being fed in the call. This would have to be tested.
Implement the widest numeric (long) every where if you have control
on the source code or create a wrapper in clojure to normalize the interactions
with the Java lib and avoid these pitfalls.
I knew this would bite someone one day, sorry that you were the one.
Can't test any of the above, no Clojure and Java on my iPad :)
Luc
> The problem is that the current behavior is not consistent with what
> you describe. Sometimes it fails, but sometimes it works when it
> should fail.
>
> And there's no documentation or guidelines about the current behavior
> at all, so it's all very confusing.
>
> My opinion is that interop is essentially ugly, so it should look
> ugly. The problem stems from the compiler attempting to not making it
> look ugly. I think it would be far better by requiring every type to
> exactly match the signature. Then there's no complex rules to
> remember.
>
> On Apr 19, 3:13 am, Softaddicts <lprefonta...@softaddicts.ca> wrote:
> > 1) Your signature has to match your java method,
> > (Foo/bar (byte 1)) will work.
> >
> > 2) There's been a long thread about this. People wanted ints and longs
> > have a similar behavior and match whatever signature is available when
> > doing
> > interop.
> > When passing (Long. 1), interop tries to match two primitive types, int
> > and long in Java method signatures. It cannot to choose on your behalf
> > between
> > two signatures that match your args, and it warns you consequently.
> > Using an explicit cast (int ...) or (long ...) would solve the issue
> > and direct
> > to the proper method.
> >
> > I did not like this idea of collapsing ints and longs when searching for an
> > interop
> > signature but at least there is a trap to tell you that you have a
> > signature "clash".
> >
> > This behavior has not been extended to bytes and shorts which are rarely
> > used
> > interchangeably with ints and longs.
> >
> > Beware, the above applies to primitive types in method signatures.
> > (Long. 1) is an object so there should be no possible confusion between the
> > Long and
> > Integer classes used in a Java method signature. They would not be
> > considered
> > equivalent candidates.
> >
> > All of the above come from the top of my head but I think it's accurate.
> >
> > Luc P.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > 1)
> >
> > > public class Foo {
> > > public static String bar(byte b) {
> > > return "byte";
> > > }
> > > }
> >
> > > user=> (Foo/bar 1)
> > > "byte"
> >
> > > public class Foo {
> > > public static String bar(byte b) {
> > > return "byte";
> > > }
> >
> > > public static String bar(Thread thread) {
> > > return "thread";
> > > }
> > > }
> >
> > > user=> (Foo/bar 1)
> > > IllegalArgumentException No matching method found: bar
> > > clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:80)
> >
> > > Is this a bug or a feature?
> >
> > > 2)
> >
> > > public class Foo {
> > > public static String bar(int i) {
> > > return "int";
> > > }
> >
> > > public static String bar(long l) {
> > > return "long";
> > > }
> > > }
> >
> > > user=> (Foo/bar 1)
> > > "long"
> >
> > > user=> (Foo/bar (Long. 1))
> > > CompilerException java.lang.IllegalArgumentException: More than one
> > > matching method found: bar, compiling:(NO_SOURCE_PATH:3:1)
> >
> > > user=> (Foo/bar (Integer. 1)) ; Shouldn't this also fail?
> > > "int"
> >
> > > user=> (def x (Long. 1)) ; same as (def x 1)
> > > #'user/x
> >
> > > user=> (Foo/bar x) ; a bug?
> > > "int"
> >
> > > --
> > > --
> > > 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, visithttps://groups.google.com/groups/opt_out.
> >
> > --
> > Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad!
>
> --
> --
> 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/groups/opt_out.
>
>
>
--
Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad!
--
--
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/groups/opt_out.
