Martin Maly wrote:
The overloaded function resolution (when IronPython calls .Net) is
currently being worked on. You probably read the original code in which
IronPython chooses the first callable alternative. The new code does
better finds out all methods that can be called and tries to choose the
'best fit'.
At the moment "out" parameters are not really taken into account when
matching up signatures, if I'm not mistaken, is this going to be addressed?
This solution is still not perfect because Python's binding ruls are
inherently different than for example C#'s and IronPython can still
arrive at an ambiguous binding. As of this very moment we are looking
into the solution that would allow program(-mer) to pinpoint the very
overloaded method to be called.
Something that crossed my mind (and I know it's not really very
"Pythonic") regarding "out" parameters was: What about passing a type in
the place of an out object, so that you can match up exactly which
overload the programmer wants to use?
I hope this helps. The code will be available in the upcoming release.
I'm looking forward to it!
A little off-topic, I was wondering about kwargs support for reflected
methods. I noticed that there is some code that deals with reflected
method kwargs, but basically excludes them from the function call and
then uses them to try and set attributes on the object. I realise that
C# doesn't really have anything like Python's default arguments (I
think...I'm no C# programmer) so kwargs aren't *quite* that useful, but
it's handy to be able to use dictionary unpacking syntax, or just to
"reorder" the arguments, more handy than having the code (try to) set
random attributes. I did hack support in, before realising that kwargs
weren't quite as useful for reflected methods, as I'd initially thought,
but it's not really something pretty.
--
Jonathan
_______________________________________________
users-ironpython.com mailing list
users-ironpython.com@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
