[Ironpython-users] TryGetNonInheritedValueHelper/TryGetNonInheritedMethodHelper

Dino Viehland dinov at microsoft.com
Thu Feb 9 06:36:21 CET 2012

The reason we don't keep looking through the type hierarchy is because we should have generated code which does the  dispatch to the base method - that's much more efficient then searching at doing a dynamic invoke at runtime.  We generate the code in NewTypeMaker.EmitBaseClassCallCheckForProperties which ultimately calls EmitBaseMethodDispatch which checks if we can do the base-method dispatch and emits the code which throws when the method is abstract.

I think what's probably happening is that we're overriding the interface slot and the class slot independently.  The class slot dispatches to the base virtual method correctly, but we see the interface method as abstract and emit code to throw.  EmitBaseMethodDispatch probably just needs to do a Type.GetInterfaceMap on the base type and map it to the correct base method if the method is abstract and the method is declared on an interface type.

From: ironpython-users-bounces+dinov=exchange.microsoft.com at python.org [mailto:ironpython-users-bounces+dinov=exchange.microsoft.com at python.org] On Behalf Of Slide
Sent: Wednesday, February 08, 2012 7:56 PM
To: ironpython-users at python.org
Subject: [Ironpython-users] TryGetNonInheritedValueHelper/TryGetNonInheritedMethodHelper

While looking a little bit into [1] I found that the two methods above in UserTypeOps.cs stop when they get to .NET types. If I remove the condition to stop at .NET types, the issue no longer appears. Is there a reason that these two methods are not looking at .NET types?



[1]  http://ironpython.codeplex.com/workitem/32166

Website: http://earl-of-code.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20120209/33a8068b/attachment.html>

More information about the Ironpython-users mailing list