This is a compile-time problem, not a runtime problem, isn't it? The
method signature has to be well-determined by the time it is written
out into the class file, so resolution happens at compile time. So it
would not break existing programs: it would break builds.
To answer how to change the spec, I'd need to understand why the boxed
Integer is more specific in this case while the unboxed int is not
more specific. I just don't know the Java spec that well to really
grok what's going on. (For the record, it's not a case of "best match"
sensibility—it's a matter of a seemingly inconsistent and edge-casey
definition of "more specific", in that boxed vs. unboxed determines
which method is called.)
~~ Robert.
On Thu, Jun 9, 2011 at 12:19 PM, Neal Gafter <n...@gafter.com> wrote:
> In Java, overload resolution finds a set of candidates and then selects the
> "most specific" of those candidates without regard to the actual arguments.
> This is in contrast to C++ and some other languages that try to find a "best
> match" to the actual arguments. There are certainly examples where one
> might prefer one or the other approach; you've found an example where "best
> match" might be more intuitive. But I think it would be a deeper change to
> the spec than we might like, and it would probably break lots of programs.
>
> Short of that, how would you suggest the specification be changed?
>
> On Thu, Jun 9, 2011 at 9:09 AM, Robert Fischer <smokejumpe...@gmail.com>
> wrote:
>>
>> Nobody is arguing that it is out of sync with the spec. The question
>> is whether or not the spec itself is buggy.
>>
>> Arguing the spec is right seems to require arguing that the most
>> coherent programming world is when this calls the first method:
>>
>> public void x(String a, Integer b, Object... c) { ... }
>> public void x(String a, Object... c) { ... }
>> x("a", Integer.valueOf(1), new Object());
>>
>> Yet this calls the second method:
>>
>> public void x(String a, int b, Object... c) { ... }
>> public void x(String a, Object... c) { ... }
>> x("a", 1, new Object());
>>
>> That seems just weird in all kinds of ways. I mean, if you were to
>> have caught me yesterday and told me that one of these two calls the
>> first method and one of these two calls the second, I would have
>> guessed it was the other way around. And I still would have considered
>> it broken (or at least annoying).
>>
>> While it may be too late for Java 7 to implement this change, is it
>> possible for this to at least be reviewed as part of Java 8? Or is the
>> spec just fixed forever, even though pretty much everyone agrees it's
>> messed up/inconvenient/suboptimal/etc.?
>>
>> ~~ Robert.
>>
>> On Thu, Jun 9, 2011 at 11:56 AM, Jochen Theodorou <blackd...@gmx.org>
>> wrote:
>> > Am 09.06.2011 17:26, schrieb Rémi Forax:
>> > [...]
>> >>
>> >> Yes, because either in Scala or in Groovy int is a subtype of Object.
>> >> There is no point to make a difference between int and Integer in a
>> >> dynamic language.
>> >
>> > at least for Groovy I can say that we see int explicitely as subtype of
>> > Object, so there what Remi says is absolutely right from our
>> > perspective.
>> >
>> > And putting my formal guy hat on I would also say that Remi is right
>> > about
>> > Java - putting the hat off - even if that is inconvinient
>> >
>> > bye Jochen
>> >
>> > --
>> > Jochen "blackdrag" Theodorou
>> > The Groovy Project Tech Lead
>> > http://blackdragsview.blogspot.com/
>> > For Groovy programming sources visit http://groovy.codehaus.org
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "JVM Languages" group.
>> > To post to this group, send email to jvm-languages@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > jvm-languages+unsubscr...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/jvm-languages?hl=en.
>> >
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "JVM Languages" group.
>> To post to this group, send email to jvm-languages@googlegroups.com.
>> To unsubscribe from this group, send email to
>> jvm-languages+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/jvm-languages?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "JVM Languages" group.
> To post to this group, send email to jvm-languages@googlegroups.com.
> To unsubscribe from this group, send email to
> jvm-languages+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/jvm-languages?hl=en.
>
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com.
To unsubscribe from this group, send email to
jvm-languages+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
