Hi,
Last Friday I promised to send more information about the progress we
are making with overloaded method resolution. The solution that we came
up with (and it will be available in the nearest release) is based on
the way IronPython uses generic types. Consider following code that
instantiates generic List:
from System.Collections.Generic import *
x = List[str]()
The index serves as a means to specify the type arguments for the
generic type parameters.
Similarily, consider method Console.WriteLine:
>>> from System import *
>>> print Console.WriteLine.__doc__
System.Void WriteLine()
System.Void WriteLine(bool)
System.Void WriteLine(System.Char)
System.Void WriteLine(System.Char[])
System.Void WriteLine(System.Char[], int, int)
System.Void WriteLine(System.Decimal)
System.Void WriteLine(float)
System.Void WriteLine(System.Single)
System.Void WriteLine(int)
System.Void WriteLine(System.UInt32)
System.Void WriteLine(long)
System.Void WriteLine(System.UInt64)
System.Void WriteLine(object)
System.Void WriteLine(str)
System.Void WriteLine(str, object)
System.Void WriteLine(str, object, object)
System.Void WriteLine(str, object, object, object)
System.Void WriteLine(str, object, object, object, object)
System.Void WriteLine(str, System.Object[])
We can use indexing to select the specific method from the overloads.
For example:
>>> Console.WriteLine[str]("Hi")
Hi
>>> Console.WriteLine[Single](3.5)
3.5
>>> Console.WriteLine[int]("Hi")
IronPython.Objects.PythonValueError: Bad args for the method <method#
WriteLine on System.Console>
>>> print Console.WriteLine[UInt64].__doc__
System.Void WriteLine(System.UInt64)
The simple types are quite straightforward. With array and byref
parameters, things get little more complicated because IronPython
doesn't have syntax for expressing the array or byref types simply. To
create array or byref types, use Type.MakeArrayType and
Type.MakeByRefType, for example:
>>> print Console.WriteLine[Type.MakeArrayType(Char)].__doc__
System.Void WriteLine(System.Char[])
>>> print Double.TryParse[str, Type.MakeByRefType(Double)].__doc__
bool TryParse(str, System.Double&)
>>> Double.TryParse[str, Type.MakeByRefType(Double)]("3.5")
(True, 3.5)
Martin
-----Original Message-----
From: Martin Maly
Sent: Friday, July 15, 2005 1:30 PM
To: 'Discussion of IronPython'
Subject: RE: [IronPython] Plans for overloads?
> Jonathan Jacobs Wrote:
>
> 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?
The out parameters are the trickiest part. The solution we are working
on will hopefully address that problem. If not (or if it is not a pretty
one for the out parameters) we will keep looking. The ultimate goal is
to achieve state where we can call any particular method without
ambiguity, and also do that within the limitations of Python syntax
(i.e. Python code object.method(out x) ... is not really an option)
> 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?
We are actually going to do something quite similar. Since I am just
beginning to write the code for the method 'pinpointing', I'll have some
results later today or after the weekend. Then I'll send along more
information.
> A little off-topic, I was wondering about kwargs support for reflected
> methods.
The kwargs support you are seeing is to enable setting properties at
construction time. For example:
import sys
sys.LoadAssemblyByName("System.Windows.Forms")
from System.Windows.Forms import *
f = Form(Text = "Hello") # <<= the call
I agree with you that the kwargs on reflected methods are not as useful
as when calling Python methods. For C# programmers that is. Visual Basic
programmer could disagree since VB supports passing arguments by name:
Public Class Class1
Public Sub Test(ByVal name As String, ByVal age As Integer)
End Sub
Public Sub X()
Test(age:=10, name:="foo")
End Sub
End Class
You are therefore bringing a very interesting point with the kwargs
support for reflected methods and we should definitely give it a
thought.
Martin
_______________________________________________
users-ironpython.com mailing list
users-ironpython.com@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
