I agree, unless Guido decides to put query syntax in CPython. Thankfully, you
don't need to add query syntax to get the benefits of LINQ, if you have the
bits in B (especially type inference, implicit typing, and anonymous types).
I'm just as happy writing:
q = db.Customers.Where(c => c.City == "London").Select(c => new { c.Name, c.Age
})
instead of
q = from c in Customers where c.City == "London" select new { c.Name, c.Age }
provided I don't have to specify generic types everywhere:
q = db.Customers.Where<Customer>(c => c.City == "London").Select<Customer,
some-unnamable-type>(c => new { c.Name, c.Age })
________________________________
From: [EMAIL PROTECTED] on behalf of Michael Foord
Sent: Fri 9/28/2007 4:17 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] Re: Object DBs - Zope/Plone vs LINQ?
Keith J. Farmer wrote:
> There are various degrees to which a language can support LINQ, in decreasing
> sweetness:
>
> A: adopt new, first-class syntax in the language to easily construct LINQ
> queries
> B: stop short of syntax, but include the features underlying LINQ: extension
> methods, expression trees, anonymous types, type inference, implicit typing
> C: allow access to the .NET libraries which implement the operations the LINQ
> pattern
>
>
I think there would be howls of protest from the Python community if the
IP team opted for A - but it would be nice to see some of the B level
features in IronPython. Maybe these could be provided at the DLR level
to support all of the DLR languages?
Michael Foord
http://www.manning.com/foord
> C#3, VB9, and a few others are at the fully-LINQ-enabled "A" level. They've
> modified the language to make access to the features listed in B and C
> transparent
>
> Unless Dino, Martin, & co have been hiding things from me, IronPython is
> still at the "C" level. Because it can access the .NET libraries, a
> programmer can manually do everything necessary for LINQ: make calls to the
> static methods on the new Enumerable and Queryable classes. Expression trees
> still need to be constructed manually to make LINQ to SQL work, but it's
> still doable, and helper methods could make things work a little smoother.
> You still get the same effect: you don't have to know SQL, you don't have to
> change your query language when you switch databases (TSQL != PL/SQL != MySQL
> != Matisse).
>
> Adding just the B-level of features would make IP very, very sweet.
>
> Incidentally, it should be pointed out for the record that LINQ isn't just
> databases. It's really any generalized data store: objects, RDBMS, and XML
> are just 3 featured applications of the pattern -- there are also web
> services, LDAP, file systems, etc. Also, in LINQ to SQL's case certainly,
> these are full-fledged queries, not simple CRUD: server-side calculated
> columns, arbitrary projections, paging operations, etc are translated into
> actual SQL and sent to the server.
>
> -- Keith J. Farmer [MSFT: LINQ to SQL]
>
> ________________________________
>
> From: [EMAIL PROTECTED] on behalf of Matt Clinton
> Sent: Fri 9/28/2007 3:42 PM
> To: Discussion of IronPython
> Subject: [IronPython] Object DBs - Zope/Plone vs LINQ?
>
>
>
> Folks,
>
> I was recently reading the July issue of Visual Studio mag, and the
> opening few paragraphs of their article on "Layer Data Access..."
> reminded me strongly of the problem solved by Zope/Plone in CPython
> land: databases with linked objects, rather than tabled varchars, bytes,
> etc.
>
> They go on to talk about how LINQ will allow storage/retrieval (CRUD) of
> CLR objects through a SQL-like syntax.
>
> Will IronPython have access to both these approaches?
> If so, there could be very terse & clean crossovers through it.
> Any reflections on when to use which?
>
> Food for thought,
> -- Matt
>
> _______________________________________________
> Users mailing list
> [email protected]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
> _______________________________________________
> Users mailing list
> [email protected]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com