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 g
That looks like an excellent, and it seems to me quite elegant, solution.
What mechanism(s) do you plan to provide for .Net callers to see IronPython
functions as "strongly typed" routines, should we want to do that?
At 05:45 PM 7/19/2005, Martin Maly wrote
>Hi,
>
>Last Friday I promised to send
How would you specify:
T4 Foo(T1, T3)
T4 Foo()
T4 Foo(T3)
T4 Foo(T2, T3)
T4 Foo(T1, T2, T3)
...? In other words, generic methods with overloads. I'm pretty sure this is
legal, but I don't have 2k5 in front of me to check.
I think you may need to add something to specify this, eg:
Foo[T1,
Perhaps ; instead of | ...
From: [EMAIL PROTECTED] on behalf of Keith J. Farmer
Sent: Tue 7/19/2005 4:02 PM
Foo[T1, T2 | T1, T3](x1, x3)
Foo[T1, T2, T3]()
Foo[T1, T2 | T3](x3)
Foo[T1 | T2, T3](x2, x3)
Foo[ | T1, T2, T3](x1, x2, x3)
<>_
Keith J. Farmer wrote:
How would you specify:
T4 Foo(T1, T3)
T4 Foo()
T4 Foo(T3)
T4 Foo(T2, T3)
T4 Foo(T1, T2, T3)
One would expect the first set of []s to classify the generic type and
the second set to specify the exact overload. This seems like the least
complicated solution (to me, any
