Current LINQ syntax is like this:
var upperLowerWords =
from w in words
select new {Upper = w.ToUpper(), Lower = w.ToLower()}
where w.StartsWith("a");
But I think that this is unnecessary breeding of C# with SQL. I believe that combination of methods with lambda calculus would be better:
var upperLowerWords =
from w in words
select new {Upper = w.ToUpper(), Lower = w.ToLower()}
where w.StartsWith("a");
But I think that this is unnecessary breeding of C# with SQL. I believe that combination of methods with lambda calculus would be better:
string[] words = { "aPPLE", "BlUeBeRrY", "cHeRry" };
var selectedWords = words.Select(
w => {return w.StartsWith("a")}
).Collect(
w2 => {return new {
Upper = w2.ToUpper(),
Lower = w2.ToLower()}
);
Any feedback appreciated.
Thanks
var selectedWords = words.Select(
w => {return w.StartsWith("a")}
).Collect(
w2 => {return new {
Upper = w2.ToUpper(),
Lower = w2.ToLower()}
);
Any feedback appreciated.
Thanks
Is the pseudo SQL syntax necessary?
Joe M.
As I recall, Abrams, etc, has a good anecdote in the first section or so of Framework Design Guidelines.
Casey875232332
I agree with you Keith on replacing from...in to foreach...in and select to yield, but I'm guessing this is impossible being that there would be no way for the compiler to know if you are using the foreach and yield in the way already defined by the 1.0 and 2.0 C# spec and this new syntax in the 3.0 spec.
Dimmy Gone Mad
versus
foreach Ident in Expression
.. I think it's disambiguated by the presence of {( + Type}
yield return Expression
versus
yield Initializer
.. To my memory, "yield" is always followed immediately by another keyword in 2.0.
Ben Fry
I'd expect MS would have the C#3 standard at ISO and ECMA prior to release (whenever that is) so that puts limits on how long they're able to think on it before they lock it down in a spec.
But then, this is why they've provided the preview.
Ivanchad
foreach
c in Customers,
l in Locations
where c.Name = "foo"
yield distinct new { PostalCode = l.PostalCode, Country = l.Country };
That's cool stuff. Has a good "feel". How much would we expect to see the syntax change between now and an official release of C# 3
MountSi
(Sorry, just spent 12 hours today trying to decode a 64-bit timestamp coming off a cell phone.. to no avail.)
AhmedQurashi
http://download.microsoft.com/download/c/f/b/cfbbc093-f3b3-4fdb-a170-604db2e29e99/Standard%20Query%20Operators.doc
The syntactical style that you're looking for is possible if you use the extension methods on IEnumerable<T> that are available when the System.Query namespace is imported.
The SQL-like syntax is compiled into invocations of these extension methods, but you can use them directly as well. I typically find myself using the extension methods directly since they are currently easier (for me) to figure out versus the query expression syntax. Although I expect this will change once there are better docs and later versions of the LINQ bits and the prototype compiler.
Kardia
That's my opinion.
Brad Teller
"from..in" -- "From" is a bad choice altogether, I think. In SQL, the direct object of "from" is the table; in Linq, it's the object in the enumerable. I'd be happy to use "foreach" in this case.
"where" -- I'm not sure there *is* a good substitute. "Where" is used in just this way in a wide variety of cases -- math, in particular.
"select" -- I think select is actually imprecise. I'd be happier with something like "yield".
var query =
foreach c in Customers
where c.Name = "foo"
yield c;
var query =
foreach
c in Customers,
l in Locations
where c.Name = "foo"
yield distinct new { PostalCode = l.PostalCode, Country = l.Country };
I do note this starts to look like the internals, which may or may not be desireable. In my opinion, it's not too bad, and builds on keywords used elsewhere for very similar purposes, strengthening the concepts used (for "yield", in particular).
Burhop
We actually had an earlier form of the query expression that looked like this:
foreach(x in foos; where x < y; yield x + x)
However, we ran it through usability testing and it did not pass. Everyone kept wanting it to look like SQL.
SMK
The query syntax is sugar for usability/readability. If you don't want to use it, then don't use it.
EBIZME
Hi Matt,
I've always been kinda curious as to how the usability test subjects are chosen. It seems That I'm frequently in opposition to many of the usability choices, and many in my circle often concur. Do you bring in influencer's and MVP's for testing What is the target persona What was the persona for LINQ Did you bring in existing users of languages like HQL
Cheers,
Scott
JohnLudlow
Frankly, I'd not complain if the Stream classes were rewritten around yield. I find it a lot more tractable to modify streams -- encoding and decoding, for example -- when I'm passing around and creating IEnumerable<T>s.
jimmieBV
I too find myself using the extension methods directly when I need to do something a bit more complex. But it's all syntactical sugar in the end though, right There's no Where() method on IEnumerable<T> - the Where() method is defined on System.Query.Sequence (I believe) as a static extension method for IEnumerable<T>. The ultimate "root" syntax for using Where() would be something like:
Sequence.Where(someIEnumerableInstance, someLambdaExpression). But don’t quote me on the syntax, the spec docs and the LINQ bits are on my other computer so I’m working without a net here.
I guess what we're talking about is degrees of syntactical sugar, and what our respective comfort zones are for particular degrees of syntactical sugar. Even lambda expressions are syntactical sugar over anonymous delegates in the end.
Query expressions share some similarities with relational query syntax because they're both query syntaxes. Both syntaxes attack very similar problems. I would think that it's to be expected that there would be some really strong resemblance, and there’s an advantage to the similarities in terms of some degree of knowledge and skills reuse. I don’t personally see the resemblance as an indication of an illusion of an underlying relational model unless I couple the very notion of a query syntax to SQL 92, and allow myself to believe that query syntaxes were born and will live and die with SQL.
I personally don't find that query expressions lead me to believe that I'm querying over a relational model just as NHibernate's HQL doesn't lead me to believe that I'm querying over a relational model. Certainly the non-necessity of joining on foreign keys a la relational query is a strong is a strong reminder that query expressions live squarely in the world of objects. But then, I don’t code much SQL anymore at all – not with NHibernate in my kit, anyway – so I’m probably not the ideal person to gauge the confusion of going back and forth between LINQ and SQL.
Presently, I find the query expressions a bit challenging – but hey… there was a time when I had to learn SQL, and there was a time when I had to learn HQL. Just another log on the intellectual fire as far as I can tell. And I gotta say that .NET makes me feel a lot warmer now that LINQ is in the picture.
Most of us need some amount of time to become acculturated to evolutions in language. I believe that the C# team provided the preview so that folks could feed ideas into the product development process. If you’ve got particular ideas about improved or alternate syntax for querying, I expect that there are folks both here on this list and at the MSDN Product Feedback Center who value the input – especially at this early stage.
Cheers,
Scott