LINQ syntax in VB.NET

LINQ syntax in VB.NET

• Carlos Lenz

  Now that we're breaking SQL compatability (which doesn't bother me at all) I'm reevaluating what I consider logical.

  I don't consider the C# syntax my best choice, just a better choice that adhering to SQL.

  'SQL-like
  SELECT user.ID
  FROM users
  WHERE user.ConnectionTime > TimeSpan.FromHours(24)
  ORDERBY user.ConnectionTime

  With this syntax my issue is that the source is qualified after the 'user' variable so the 'user' variable type can't be infered from the 'users' collection. As a VB Coder I love me some Intellisense, so this option is strictly forbidden.

  'C#
  FROM user IN users
  WHERE user.ConnectionTime > TimeSpan.FromHours(24)
  ORDERBY user.ConnectionTime
  SELECT user.ID

  While this is functional, I don't like the SELECT being last, nor do I like the 'user IN users'
  because I feel like (SQL haunting me) SELECTing should precede qualifications for the SELECT (WHERE) and definately sorting. But maybe I'm just being petty.

  As for user IN users, FROM should qualify the source collection not the ... temp variable or whatever. and that IN keyword bothers me. But I suppose the heart of it is that it becomes redundant if SELECT is moved second

  'VB9.0 Suggestion
  FROM users
  SELECT user.ID
  WHERE user.ConnectionTime > TimeSpan.FromHours(24)
  ORDERBY User.ConnectionTime

  This solves the intellisense, is a bit closer to SQL (if that's the kinky kinda thing you're into) and gets rid of that IN thing. Come to think of it it's really just switching SELECT and FROM from the SQL order which is sufficient adjustment to me.

  Just an aestetic suggestion I guess...
  

  
  
  

• Marcelo Jorge

  It would be exciting to have a purely object oriented way of doing it:
  
  users.Where(ConnectionTime > TimeSpan.FromHours(24)).OrderBy(ConnectionTime).Select(ID)
  
  It would make the code more object oriented like the smalltalk way of doing it.
  
  

• Ricardo Mendes

  Being an XQuery "guru", I like the C# syntax approach better as well. You may want to let the VB guys know that you prefer the FROM first and SELECT last. As mentioned elsewhere, we can still hope... :-)

   

  Michael

  <Tony Valenti@discussions.microsoft.com> wrote in message news:9e339fc6-dd73-4847-9015-6260f08f7cf4@discussions.microsoft.com...

  I don't know if this had anything to do with the C# syntax, but one of the things I really like about having the FROM statement first is that mentally, I think it makes more sense - I know the Source of objects then I know the filters that are placed on them as opposed to SQL where, with large statements, you'll have to scroll to the bottom to find where the source is.

  
  

• Alexander Yarushin

  Hi Martin --
  
  We're listening right here; this is the forum to deliver feedback to the VB language design team. 
  
  You guys are right about our motivations -- we want the syntax for LINQ in VB to be very natural for users familiar with SQL to read and write. Of course, there are some challenges ahead regarding Intellisense. One of the pieces of feedback we've heard loud an clear from all the LINQ discussion is that good Intellisense is *critical*. Stay tuned for an upcoming release which will provide a glimpse of what we're planning for Intellisense with regards to LINQ. If the feedback is that the Intellisense experience doesn't cut it and it can't be fixed, then we'll strongly consider changing the syntax. One of the reasons we're getting this out to you all so early is so that we can get feedback and respond to it.
  
  Thanks for taking the time to play with the preview bits!
  
  Thanks again,
  Amanda Silver
  
  Program Manager
  Visual Basic
  

• diling00

  Welcome to the wonderful world of type inference.  It even works with generics and anonymous types... ;)

  users.Where(user => user.ConnectionTime > TimeSpan.FromHours(24))

  For example, if users is of type List<User>, then the Where extension method will expect a predicate that accepts type User.  If users was instead a DLinq table of User, the Where extension defined for that would expect an Expression tree whose argument type was User.  This is a difference in the signatures for the Where extension defined for IEnumerable<T> and the Dlinq table -- the compiler sees the type expected in the slot where the lambda exists, and creates the appropriate structure (anonymous delegate, or ExpressionTree) at that point.

   

  
  
  

• Daniel M&amp;#228;chler

  That would be great, although I don't know how strong typing can be enforced in this type of queries, which involve instance members of the elements of the collection.

  
  

• Nuno31415

  Martin Unterholzner wrote:

  Since I know now that the VB team is listening right here, I would like to aks something about the language future in general: Are there any considerations to add some Design by Contract features to the .NET languages in the future like the pre- and postcondition principle proposed in spec#

  
  
  This is definitely something we think about as we think about the future. As you say, it would need to be something supported by the entire platform to be most useful, so it would obviously be a big thing. Time will just tell... :-)
  
  Paul
  VB Team
  
  

• HuberSepp

  Ok, As a VB.NET developer I prefer the C# way, too. Jumping back and forth is not a good thing. :-)

  
  

• photoval

  Hi AmandaS
  
  Thank you for your reply.
  My argument was motivated only by the challange of having a good IntelliSense without jumping back and forth on the code. If this problem can even be solved keeping the SQL keyword order it will be fine of course.
  
  Since I know now that the VB team is listening right here, I would like to aks something about the language future in general:
  Are there any considerations to add some Design by Contract features to the .NET languages in the future like the pre- and postcondition principle proposed in spec#
  
  

• Spetluri

  >Now I have learned that the VB.NET implementation is not turned around, it's more like SQL, and I wonder why...
   
  First, keep in mind that what's out now is just an early preview, and syntax may change before release. I think the reason they did it this way is that they think many existing VB users are familiar with SQL.
  
  But then you soon realize that it isn't SQL and the similarities don't go very far. That's one of the reasons C# did it differently. And personally I, like you, prefer teh C# way.
  
  
  >Are we gonna lose IntelliSense over this
  
  No you'll get IntelliSense alright. It may just have to make you jump back and forth a bit in the code to help you complete the statement.
  
  
  
  

• RedKMan

  Hi Paul
  
  I can immagine that this feature would be a big thing because it would need the extension of the .NET common intermediate language, since it would require a theorem prover mechanism. However, this feature would probably be worth the huge effort by giving the developers a strong tool for writing quality software. Hopefully we will have something like that in .NET 3.0 ;-)
  
  

• byroman

  LINQ lets you write that type of queries as well. The keywords are mostly "syntactic sugar".
  
  
  
  

• olsen.chris

  Hi
  
  I think the C# query keyword order is more convenient and probably most of the VB will agree with that. The question is how can we reach the VB language developer team to tell them about our preferences Is there a forum dedicated to proposals for future language improvements
  

• Mike Driest

  I don't know if this had anything to do with the C# syntax, but one of the things I really like about having the FROM statement first is that mentally, I think it makes more sense - I know the Source of objects then I know the filters that are placed on them as opposed to SQL where, with large statements, you'll have to scroll to the bottom to find where the source is.
  
  
• LINQ syntax in VB.NET