|
|
|
This doesn't fix the issue at all but another workaround is to use a generator expression instead of map() + a closure: http://boo.codehaus.org/Generator+Expressions
return array(double, double.Parse By the way, the compiler is able to tell the array type by its own
try this: value = array(double.Parse(value) for value in ("1.0", "3.15"))[-1] Yes, that's a good workaround for some cases more than others.
(I can't make "def Apply(function as callable, value as duck): I don't suppose there is a way to delay looking up overloaded functions until they've been invoked? Take a look at the InvokeMember function - you may be able to use it for your example (I don't have time to delve into it right now). See http://docs.codehaus.org/pages/viewpage.action?pageId=13653
This doesn't implement this feature, but it fixes a related compiler exception.
This line of boo code will cause the compiler to throw an exception: f = double.Parse To change it to an ambiguous reference error instead, change line 2266 of ProcessMethodBodies from this: if (NodeType.ReferenceExpression == node.NodeType && to this: if (node is ReferenceExpression && This fixes the problem because double.Parse for example is a memberreferenceexpression, which is a subclass of referenceexpression. I didn't catch that events weren't working, such as: AppDomain.CurrentDomain.AssemblyResolve += AssemblyResolve
because an event is a memberreferenceexpression that is still ambiguous internally (field + event of same name) at the time PostProcessReferenceExpression is called. So this version makes exceptions for events: if (node is ReferenceExpression && Perhaps the compiler could create a method that dispatches to the right overload at runtime, like below. Otherwise, the ironpython solution is to specify the types in brackets after the method name like so, but I would have thought that this would conflict with generics: r = System.Random().Next[int](10,20)
def __parse(*args): //method created by compiler d = __parse //replacement for double.Parse print d("34.3") The solution I proposed in last comment wouldn't really work well with instance methods, only static methods. Here's a way that would work with instance or static methods by creating an ICallable class, but I don't know if the speed hit is so bad as to make this option undesirable:
class A: //This is created automatically by the compiler: a = A() this sounds interesting, specially as a way to enable multimethods:
class Foo: a = functionReturningObject() // with your proposal interesting... I didn't notice if we use ICallable, we lose the return type since ICallable.Call returns object. So here's a version that just uses a regular class with an Invoke method that does the dispatching:
class A: //This class is created automatically by the compiler: a = A() Isn't Doug's last comment exactly what's being done currently, with the dynamic dispatcher thingy?
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
That changes the entire scope of the issue.