[IronPython] Future handling of op_Implicit

[Giles Thomas]

Thanks, Dino - I've voted on the bug, thanks for pointing me in that 
direction.  It would be great to be able to avoid writing C# for this.


Regards,

Giles

Dino Viehland wrote:
> 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
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   

-- 
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