[IronPython] CLS compliance

[Peter Mechlenborg]

Thank you for the detailed explanation.

Dino Viehland wrote:
 > Great summary of the problem space.  First, let's look at your first
 > Point class.  One aside on the CLR: we do have the concept of value
 > types & reference types so int is a primitive.  But the CLR also
 > supports boxing (and C# has auto-boxing) so we can just box that int
 > up into an object.  We can then do the cast back to an int which will
 > unbox it (the cast is also C#'s syntax for unboxing value types).
 >
 > We currently have 2 different ways in which built-in functions are
 > called.  One is via our ReflectedMethod class which uses a late-bound
 > dynamic invocation after using reflection to match parameters
 > (including overload resolution).  The other code path is our optimized
 > path using BuiltinFunction's where we generate a dynamic method that
 > will perform the method binding and do an early-bound (early here
 > being defined as at the time the dynamic method is generated, but it
 > still doesn't happen at call time).
 >
 > That has me jumping to the end of your mail: this is how we handle CLS
 > consumption.  We also allow CLS extension (you can derive from
 > built-in types) by dynamically creating a single CLS class that
 > derives from the base class (actually a single class for each
 > object/interface combo).  This class will override all of the virtual
 > methods w/ a helper function that will check if the user has replaced
 > the function from Python.  Therefore:
 >
 > class foo(list):
 > 	def __getitem__(self, index):
 > 		return 'abc'
 >
 > and you pass an instance off to C# code:
 >
 > 	object ConsumesAList(IList foo){
 > 		return foo[0];
 > 	}
 >
 > returns 'abc' and not the IronPython List's implementation's get_Item.
 > So that's how you can actually inherit from a built-in type in the
 > CLR.

Ok, that seems like a much better solution than the delegation stuff I
wrote about.

 >
 > Ok, so now we get to the production side of things...  All the options
 > you mention are possible...  For our CodeDOM implementation we will
 > consume @accepts and @returns syntax (as described in PEP 318 and
 > implemented in the non-standard typecheck library).  This is the
 > 'extra decoration' approach to getting the type information.

Ok.

 >
 > Inference is nice but it also has additional problems.  Even if we
 > infer the types you're using or expecting correctly, how do we know
 > those are the types you want?  Maybe you really want to expose
 > something that accepts objects!

Yes, that's correct, I hadn't thought about that.

 >                                  And ultimately exposing APIs that
 > only take objects isn't that bad.  It allows C# code to call the
 > Python code, and it allows the Python code to receive anything it
 > wants.  The C# programmer is a little upset because they don't get
 > their rich type info but that's tough for them, Python APIs will
 > accept any inputs.

:-).  I guess there will always be a dilemma about whether typed
languages should take precedence over untyped, or the other way around.

 >
 > The other interesting case here is inheritance where we presumably do
 > know the real type information, and can therefore generate correct
 > overrides.
 >
 > But I don't personally see that as the biggest problem.  I'd be happy
 > to live in a world where my Python code only exposed object
 > signatures, at least as a starter solution.  To me the biggest issue
 > is how can we maintain Python compatibility while at the same time
 > creating this static-type view of the Python world.
 >
 > That problem starts with class definitions (in Python class
 > definitions are executable statements) and carries through to doing
 > things like changing a method at runtime (where a normal CLS producer
 > should call the changed method, not the statically compiled method).
 > And obviously there's lots of other challenges in this space as well -
 > hence the reason we don't yet have a solution here :)

This is definitely a hard problem.  In my opinion the CLR and also the
JVM are too focused on static languages (not just static types).  This
makes it difficult to target image based language, such as Smalltalk
and Common lisp to, and I guess also Python and Ruby, on these
platforms.  The JVM is getting a dynamic-invoke instruction, and I
think this will make it much easier to target the JVM with dynamic
languages, do you know if similar plans exist for the CLR?


Anyway, keep up the good work, stay cool, and have fun,

   --  Peter