[IronPython] Interaction with other CLR code

[Curt Hagenlocher]

One of the things which would make IronPython more interesting would
be to allow it to interact with other CLR code on a "first class"
basis.  As I see it, there are two components to this problem:

1. A Python object should have the ability to look like a more
"regular" CLR object.
2. It should be possible to load a Python object from an assembly
using a different (arbitrary) language.

The first problem is potentially a lot simpler than the second,
and the remainder of this message will focus on it.

The easiest way to expose an object's methods to decide that
we're going to do it through a CLR interface.  The actual interface
implementation will consist of shim functions which defer to
the Python implementation in the usual dynamically dispatched
manner.  I see at least three architectures:

1. Create a shim class per interface.  The classes can be cached,
so that they only need to be emitted once per interface.  Either
a new instance of the shim class can be instantiated every time
it's needed or the shims can be stored on the object.  This approach
allows silent type coercion when passing a Python-defined object
to a function that expects a specific interface as a parameter --
though that is of questionable value.  The usual way to wrap the
object in an interface would be to call a system-defined function
for that purpose.

2. Create a shim class per set of interfaces.  This approach is
similar to the first, except that a single shim class can implement
multiple interfaces.  This would require more complicated caching
logic, and may result in more emitted classes being defined.  What
you would gain is the ability to cast IFoo to IBar, if the object
in question defines both.

3. Define all the interfaces directly on the CLR base class for
the Python class.  For "classic" Python classes, the base class
is always IronPython.Objects.OldClass, and it probably doesn't
make sense to provide interface support here.  But "new style"
classes have a dynamically-generated base class currently created
as "IronPython.NewTypes." + typename of CLR base class.  (The
default CLR base class is, of course, System.Object.)  Taking this
approach would again require more complicated class caching logic,
and would result in more emitted code, but it probably results in
the most natural usage pattern, allowing the following:

	class foo(ISerializable, IList):
		[...]

As an aside, it is currently possible to do the following:

	class foo(Some.Other.CLR.Class):
		[...]

and have "foo" actually derive from that class.  There isn't any
way to override the virtual methods in Some.Other.CLR.Class, though.

--
Curt Hagenlocher
curt at hagenlocher.org