[IronPython] Future handling of op_Implicit

Dino Viehland dinov at exchange.microsoft.com
Sat Jul 7 01:55:09 CEST 2007


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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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
giles.thomas at resolversystems.com
+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 at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



More information about the Ironpython-users mailing list