Posted By: The Channel 9 Team | Jun 16th, 2004 @ 3:03 PM | 210,414 Views | 31 Comments
Anders talks about a feature he's working on for C# 3.0 that aims to make data programmable in a general purpose and truly object oriented syntax; something that just doesn't exist today.
Tag: CSharp
Media Downloads:
Rating:
0
0
Corvax
Corvax
Corvax

Do you think it will be easier to change data access model instead of programming language? I know the WinFS team has many good ideas in this area. I would prefer to access data from a programming language directly by URL and object model. For example:

{
  Database db = new Database("db://amazon.com");
  XML list = db.Search("Author like 'Hugh Darwen'");
  foreach (XML book in list) {
    wishlist.Add(book.Title + ", " + book.ISBN);
  }
}

哪位知道Anders Hejlsberg的blog.暂时还是用delphi.不过c#很棒的。

tcholzer
tcholzer
Vita contingit, vive cum eo.

I think that is terrific for C#, however, to be accurate that ability does exist today in MSFT Visual Foxpro.

Anders doesn't have a blog, but I do. 

I'd be happy to convey what information that I can about data programming in C# 3.0. 


recently ms research had relased prev comega compiler and some docs

http://research.microsoft.com/Comega/

COmega has a lot of data integration concepts built into it.  Will any of these appear in C# 3.0?  I can't say exactly, except that I was the developer that put them into COmega.  Small world.  Wink

I agree with yag, it should definatly be a cross-language team (and one would assume it would be given the depth of the undertaking). I look forward to more posts to give some understanding of how this develops... (i.e. if it expands/encompases COmega or not).
yag
yag
yag
This is a cross-language (and cross-team and cross-division) effort. You'll be seeing more and more over time.

yag
joe.wurzburger
joe.wurzburger
Scary, I know
God, this is so true.  It seems like we spend half of the time in our shop writing freakin' queries inside of our DAL, mapping database types to DAL types and presentation-layer types, and other flavors of data-related plumbing.  It used to seem like debugging was all about finding where I'd accidentally stomped on memory or mismanaged a pointer ... now it seems to be all about a bad character in a SQL string or handling DBNull.Value correctly.

If there was some compiler awareness of and native control over database constructs, it would be like butter.
Microsoft Communities