[Python-Dev] convertibility

David Abrahams dave@boost-consulting.com
Sat, 24 Aug 2002 12:09:28 -0400

From: "Alex Martelli" <aleax@aleax.it>

> 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
> 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:

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.


           David Abrahams * Boost Consulting
dave@boost-consulting.com * http://www.boost-consulting.com