On Tue, Dec 22, 2009 at 4:19 PM, Keith J. Farmer wrote:
> Rewrites to use extensions methods need to happen with knowledge of what
> extensions are available at that instant, and should defer to what's defined
> on the object in question when possible. Unless carried in the AST, this
> knowled
onment, so probably best
done by the DLR itself, neh?
-Original Message-
From: Jeff Hardy
Sent: Tuesday, December 22, 2009 14:23
To: Discussion of IronPython
Subject: Re: [IronPython] LINQ from IronPython
On Tue, Dec 22, 2009 at 11:49 AM, Dino Viehland wrote:
> Personally I like the 2
On Tue, Dec 22, 2009 at 11:49 AM, Dino Viehland wrote:
> Personally I like the 2nd option. I think only the 2nd and 3rd are
> really viable. The one important thing to keep in mind here is that
> importlib may become the default importer in the future. So any hooks
> here need to be based off o
.ironpython.com] On Behalf Of Jeff Hardy
Sent: Tuesday, December 22, 2009 2:12 PM
To: Discussion of IronPython
Subject: Re: [IronPython] LINQ from IronPython
On Tue, Dec 22, 2009 at 2:39 PM, Dino Viehland wrote:
> The really interesting thing to me is that this is a closure - either id is in
&
On Tue, Dec 22, 2009 at 2:39 PM, Dino Viehland wrote:
> The really interesting thing to me is that this is a closure - either id is in
> a nested function scope or it's in a global scope. I'm not sure how that gets
> transmitted across the wire. Do closures work in LINQ in C# going across to
> a
Jeff wrote:
> I would guess that most of those lambdas are going to be fairly
> simple, and hopefully easy to type-infer. For ones that aren't
> inferable, the best option would be to give an error.
>
> Given:
> id = 1
> customers.Where(lambda c: c.Id == id)
>
> Would IronPython be able t
On Tue, Dec 22, 2009 at 2:07 PM, Dino Viehland wrote:
> 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 conversio
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'
on of IronPython
Subject: Re: [IronPython] LINQ from IronPython
On Tue, Dec 22, 2009 at 10:11 AM, Dody Gunawinata
wrote:
> I am not well averse with generator expression, but I think it will have
> problem supporting the 9 keywords in LINQ Query Comprehension Syntax so
> sticking to extension
r 22, 2009 10:49 AM
To: Discussion of IronPython
Subject: Re: [IronPython] LINQ from IronPython
Jeff wrote:
> Extension Methods
Personally I like the 2nd option. I think only the 2nd and 3rd are
really viable. The one important thing to keep in mind here is that
importlib may become the defa
On Tue, Dec 22, 2009 at 10:11 AM, Dody Gunawinata
wrote:
> I am not well averse with generator expression, but I think it will have
> problem supporting the 9 keywords in LINQ Query Comprehension Syntax so
> sticking to extension methods would make more sense.
I wouldn't expect support for the wh
Jeff wrote:
> This is one of those things that I've been pondering for a while, so I
> thougt I'd throw it out there and see what everyone else thinks (I
> fully expect to hear that I'm crazy...). I'd like to be able to query
> an existing data model (Entity Framework in this case, but that's not
>
I am not well averse with generator expression, but I think it will have
problem supporting the 9 keywords in LINQ Query Comprehension Syntax so
sticking to extension methods would make more sense.
C# LINQ Query comprehension is purely syntactic (
http://blogs.msdn.com/ericlippert/archive/2009/12/
This is one of those things that I've been pondering for a while, so I
thougt I'd throw it out there and see what everyone else thinks (I
fully expect to hear that I'm crazy...). I'd like to be able to query
an existing data model (Entity Framework in this case, but that's not
important) from IronP
14 matches
Mail list logo