Re: Bug report: can't overcome Java method ambiguity in some clear cases

Fair enough. If someone writes "1.0", it's reasonable to expect they had a floating point in mind. We are probably prematurely "optimizing" the constant 1.0 to an int. I opened to track this. Attila. On Oct 9, 2013, at 4:43 PM, Andreas Woess

Re: Bug report: can't overcome Java method ambiguity in some clear cases

I see your point, but once again I'm very worried about: 1) How much Nashorn diverges from not only Rhino, but also many other JVM languages. 2) How much Nashorn diverges, in my humble opinion, from the spirit of dynamic languages, which generally prefer to plough through ambiguities rather th

Re: Bug report: can't overcome Java method ambiguity in some clear cases

Well, as I stare at it, I think this should be ambiguous. Based on JS conversion rules, both methods are applicable, and neither method is more specific than the other. I'd say this worked incidentally in Rhino, because it probably just picked the first signature that matched. Just convert your

Re: Bug report: can't overcome Java method ambiguity in some clear cases

I'd like to add to this bug report: jjs> new java.awt.Color(0.5,0.5,0.5) java.awt.Color[r=128,g=128,b=128] jjs> new java.awt.Color(1.0,0.5,0.5) java.lang.RuntimeException: java.lang.NoSuchMethodException: Can't unambiguously select between fixed arity signatures [(float, float, float), (int, int,

Bug report: can't overcome Java method ambiguity in some clear cases

Here's a particular exception I got: java.lang.NoSuchMethodException: Can't unambiguously select between fixed arity signatures [(java.lang.String, java.lang.String), (int, java.lang.Object)] of the method org.restlet.util.Series.set for argument types [java.lang.String, java.lang.Integer]