[IronPython] why?

[J. Merrill]

I had not intended to go off-list, so in the hopes that people want to hear the accidentally-private discussion (or at least won't mind!), here it is.  (Curt was responding to my comments, shown with two > signs.)

At 03:55 PM 9/15/2004, Curt Hagenlocher wrote

>> Given that set_Enabled is not overridden, FePy should clearly know
>> to cast 1 to boolean and pass that value.  Did I suggest that there
>> be no implicit conversions?  I hope not; it's one of the things
>> that makes dynamically-typed Python so usable.
>
>Sorry... I'm just projecting from the code I've read.  There does
>not appear to be special-case code for non-overloaded functions.
>(And I'm not sure why I started calling them "overridden" instead
>of "overloaded".)  The ReflectedMethodBase class stores an array
>of MethodBase -- if there is no overload, then the array has one
>element, otherwise it has more.  Naturally, it would be possible
>to change this behavior.
>
>> Let's change the name to SomeFunction for the rest of this
>> discussion, as it would be a bit odd to name a function to
>> which you could pass non-booleans CallBoolFunction.
>
>Good point.
>
>> If there are overrides of SomeFunction, what we want is for
>> FePy to figure out which one has the signature that "best
>> matches" the Python value 1.
>
>So, it sounds like the simplest and cheapest idea would be to
>add a flag to Ops.ConvertTo (or to create a different version)
>that would control how liberal we want to be in type conversion.
>We can go through the loop once with the value set to "strict",
>and then again with the value set to "liberal".
>
>> However, it should prefer to cast 2 to string than to boolean.
>
>Yes, but there's a performance cost for doing that.  As you 
>point out, we need multiple loops with steadily decreasing values
>of "strict", or we need to calculate the "goodness" of each possible
>overload and then take the "best" one.
>
>> (Of course, it would not have to do the .NET metadata query
>> twice, as it could cache the results.)
>
>It already is caching the results.
>
>> I really should take a look at the source to see how hard such a
>> change would be.
>
>Objects/ReflectedMembers.cs contains the "pick an overload" code,
>and the actual conversion happens in Objects/Ops.cs.  In both
>files, look for the function Ops.ConvertTo.
>
>By the way, our last two exchanges have been off-list.  I assumed
>that you had gone off-list on purpose, but in retrospect, you may
>have been tripped up by the "Reply" options (as I have been, on
>occaision).
>
>--
>Curt Hagenlocher
>curt at hagenlocher.org 


J. Merrill / Analytical Software Corp