From: "Alex Martelli"
On Saturday 24 August 2002 04:00 pm, Samuele Pedroni wrote: ...
[yes with type categories or adapt we could do better, but the design prefers to minimize unexpected behaviour, and in practice is not too much constraining]
As a happy user of Jython (albeit, so far, in modest amounts, and not yet in production-code), I want to add an unsolicited testimonial -- most of the time, the rules Jython applies "do what feels right" and prove (to me) unsurprising and unconstraining.
After studying the rules in detail, particularly with overload resolution in mind, I was afraid of many possible mishaps. In practice, I find that it seems the rules don't get in my way and don't trip me up either. Whatever it is, there IS something right in those rules (perhaps just in conjunction with typical Java libraries, or perhaps more generally).
Hmm. When did Java acquire overload resolution? I was surprised to see it here: http://developer.java.sun.com/developer/TechTips/2000/tt0314.html I was thinking of taking advantage of these rules for Boost.Python (and Python itself), but I'm a little worried about the applicability of the final part of the rules: if any method still under consideration has parameter types that are assignable to another method that's also still in play, then the other method is removed from consideration. This process is repeated until no other method can be eliminated. If the result is a single "most specific" method, then that method is called. If there's more than one method left, the call is ambiguous. This rule is similar to the one used in C++ for partial ordering of function templates. The problem is that my convertibility criteria examine the actual objects involved in a conversion, not just their types. This allows us to overload on sequence-of-float vs. sequence-of-string, for example. Substitutability of argument types can't be tested without exemplars of those types to work with. -Dave ----------------------------------------------------------- David Abrahams * Boost Consulting dave@boost-consulting.com * http://www.boost-consulting.com
participants (1)
-
David Abrahams