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.
