[IronPython] LINQ from IronPython

Dino Viehland dinov at microsoft.com
Tue Dec 22 22:07:58 CET 2009


Keith wrote:
> I greatly prefer the C#-ish import rather than "clr.Extend".  Beyond
> that, explicitly importing the extending class could have benefits that
> were noted back when LINQ was introduced:  it's possible for a single
> namespace to have conflicting extension methods.  The moment there's
> conflict, you lose the extension method syntax.  Therefore, my
> suggestion is for the second method (and not for the IMHO-abused
> "explicit better than implicit" reason people give).
> 
> As for expression trees:  I wouldn't expose the DLR's AST.  Instead, I
> would expose the same trees that C# and VB expose.  The reason being,
> of course, is that these would be what mainstream LINQ implementations
> would target, LINQ to SQL in particular.  For the most part, that
> should be a simple transformation, and could be performed at runtime.
> That is, implicitly replace a call:
> 
> 	MethodExpectingExpressionOfFunc(lambda x: x.Foo + x.Bar)
> 
> with
> 
> 	MethodExpectingExpressionOfFunc(DlrToClrExpressionConverter(lambd
> a x: x.Foo + x.Bar))

Assuming this is DlrToClrExpressionConverter is converting the expression
tree and not a call in the produced expression tree the difficulty is
performing the type inference of the expression tree.  In this case 
presumably the conversion to Expression<T> informs us of the type of
x.  From there we could know that it did indeed have Foo and Bar properties
and those were of some addable type.  And so we could probably produce
a valid expression tree.  Not exactly a "simple transformation" but 
we could probably usually pull it off for code like this.  I'm not sure
how predictable it would be when we could or couldn't pull it off though.







More information about the Ironpython-users mailing list