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