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
