Attila Szegedi wrote: > Also, I'm talking solely about the problem of selecting among > overloaded Java methods invoked from a dynamic language here. Dynamic > languages are better off without a concept of an overloaded method > altogether, as they can mostly have a single method accepting any > types of arguments anyway :-)
This is the impression I got; I believe dispatch to purely Java types should not violate Java method dispatch once you pass the "half-way" point of invocation. There may be coercion that happens on incoming arguments, but coercion should produce predictable results, and based on those results, method dispatch should occur according to JLS. Now how we coerce those arguments into a "prepared" set of types is up for debate, and language-dependent. But I think it's a bad design for the calling language to be able to unduly influence the method selection logic other than through regular type conversions. > So I believe that it's OK to conservatively do automatic type > conversions as long as the situation is 100% unambiguous, but as soon > as the choice is not black and white, it's not a shame to bail out > with an error and let the programmer narrow the types as necessary at > the problematic call site, i.e. see above trick of using !! to force > an expression to be boolean. For exactly this reason Ruby (and by extension JRuby) has only a handful of coercion mechanisms (to_str, to_ary, to_hash, and a few others). Following this design, JRuby only has a handful of automatic coercions to Java types; Ruby Strings are coerced into Java Strings, Ruby Numeric types are coerced into the smallest numeric type they'll fit, and so on. Beyond that, we pass the actual object itself, so if you're not using one of the core integral types, you're working with custom composite types. Providing the ability to add implicit coercion to arbitrary custom types may be useful, but I think it's also a path to a really confusing language. Or let's phrase it another way: I think it should be considered a library or framework feature, as in Rails, rather than something the language does out of the box. That way you can know ahead of time you're dealing with a particular framework and its altered mechanisms for type coercion, rather than having everyone using the language mutilate it in undetectable ways. But maybe I'm more of a minimalist. > What happens if two sets of parameters end up the same cost? Flip a coin? :) - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
