I believe we're going to get better at this in the future. For starters there are currently some code paths which are missing the checks for the implicit conversions - for example if you define an implicit conversion to string we won't respect it all (in either v1.x or v2.x right now). This is because we have a fast path which isn't checking for the implicit conversion.
Additionally it would be fairly easy for us to expose this out via some other mechanism for when we're not doing the right thing. For example we could either leave the op_Implicit methods on the type which defines them or maybe we could move them onto the type which we want to do the conversion from (e.g. add a "ToFoo" onto Bar when Foo defines an implicit operator for conversion from Foo to Bar). I believe w/ the 1st option we can get into trouble w/ overloads that only differ by return types but the 2nd option may be less problematic. But obviously we've got to do a better job of enabling this basic CLS consumption scenario w/o forcing you to use C#. We've also run into this internally recently as a fundamental DLR concept. That's how we discovered the issues w/ string conversions :). If you haven't already vote on bug #11278 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=11278) please do and we'll look at doing this sooner rather than later. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Giles Thomas Sent: Thursday, July 05, 2007 8:43 AM To: Discussion of IronPython Subject: [IronPython] Future handling of op_Implicit Hi, I guess we're going to have to use C# to work around the lack of op_Implicit support in the short term, but I'm interested in knowing about the IP team's plans for handling conversion operators going forward. Here's our situation; we have a highly-scriptable application, and our clients want to be able to call their own .NET libraries from their scripts. However, their libraries make heavy use of the implicit casts, so that they can (for example) have a method that takes an instance of C1, but pass it a C2 and rely on C1's op_Implicit(C2) to handle the conversion. This works fine for them when using other .NET languages, but of course doesn't work in IronPython. I must admit that I don't really know what IP could do with this kind of code; if I understand correctly, op_Implicit(x) in (say) C# is dispatched based on the type of the variable x rather then the type of the object to which it is a reference, and of course variable type in that sense is not a meaningful concept in a dynamic language. What should IronPython do? Is this a case where people are going to have to write more code if they want to use a dynamic language? Regards, Giles -- Giles Thomas [EMAIL PROTECTED] +44 (0) 20 7253 6372 Resolver Systems Ltd 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK _______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
