C# 4.0 - Questions and reasons behind the answers

I think I've watched that bit of Anders presentation at PDC 2008 where he cons's up a eval loop using C# '5' more than half a dozen times now. Reminds me of the F# demo Don did a while back where he created and hooked up a WinForm on the fly. Having this in C# will be utterly cool and I really hope Anders et al can make good on their hopes of getting the 'eval' stuff out to us some time before Visual Studio 2012! Huge kudos to the whole C# team, your compiler continues to be a big contributing factor to my on-going love affair with programming!

As usual, Anders presents us with all the goodies, packaged up in time for Christmas. A paedagogical talent as well.

I completely agree with the question on covariant return types. When I met Anders at the PDC bookstore I really tried to get the message across and I've been pushing the request for a long time (as have numerous other people in the community).

When can we have a downloadable document about the C#4 language?   There is already one for C#3.   I am looking forward for a downloadable document for C#4.

Oh, this is really cool! I met Charlie Calvert at this MVP Open Day in Beijing, but I never met Anders yet. I'll download this video later, and thank you all in this video.

Anyone else having trouble viewing the videos on the site? None of the video links work - only audio.

Love Anders and would not presume to know anything compared to him, but did he really say XElement is a good alternative for VBs XML support?  I think I would rather chew glass.  Sure you can make it easier with an extention method like:

 var xml =
@"<Users>
    <User>user1</User>
    <User>user2</User>
</Users>".ToXML();
Console.WriteLine(xml.ToString());

        public static XElement ToXML(this string xmlString)
        {
            return XElement.Parse(xmlString);
        }

But that lacks two major things, compiler support and designer support.  Naturally, it becomes a slippery slope of what meta languages to support as the next question becomes support for JSON and M.  I think M makes this more interesting as I think we will need compiler support for that.  So should M, JSON, and XML have compiler support in c#?  Why or why not?  Could these be opt-in/opt-out extentions to the language?

Another great vid from Anders. I don't have an especially smart comment other than to say I appreciate these and look forward to the next time we see him on Ch9.

Must come as a matter of taste.  I strongly prefer the XElement method to the VB inline method.

No difficulties in having to line up ending tags.  Its XML exploiting the C# parser.

Will Visual C++ status quote  be enough to overcome the appeal of the D programming language in 2010?or is C# going to be unleashed? 

Why doesn't Visual Studio provide for two forms of compilation.  For example the exiting just in time and full compilation of the MSIL to  machine code.  I really see that C++ at this stage only serves for the purpose of maintaining legacy code.  The incarnation of C++ was a hack and will continue to grow as a hack.  .Net languages (in particular C#) for one should take full charge of future development in both desktop, web and yes system development. D programming language is already making an impression on  a small but growing  C++ community.  D programming languages has syntactic appeal of C# and the horse power of C/C++.  So what is the constraint,  religion or technical feasibility. DotNet languages will be competing against the up an coming D programming languages sooner or later for development of system software and embedded systems. Again I say C++ is dead weight and should only be relevant for legacy code (in other words C++ will soon be Cobol).  C# (all .net lingos) can easily take the manto if Visual Studio provided for this option and full support for "producing"  applications that are true  platform independent. 

Well, I can see a some nice scenarios to use this.

But I had hoped for something much more powerful

private string Foo(int x)
{
    return x + 10;
}

public DoSomeThing(Method name)
{
    var fooValue = name(10);
}

public Caller()
{
    DoSomeThing("Foo");
}

That's what I call dynamic OR even more useful, dynamics for class names also.

Thanks for this discussion. As we train ourselves to think in terms of Abstraction when programming we many time find ourselves purposely genericizing the type.  Passing objects in and out of methods becomes attractive with repsect to Abstraction.  The problem of course is in the reconstruction of the Object into statically typed objects just for the sake of calling a method.  As you mentioned using the Reflection class does indeed become messy (and actually predates things such as the HTML DOM (for example MethodInfo and FieldInfo) are not terms used within the HTMLDOM, so we have to convert mentally when trying to work with HTML DOM that a Reflection.MethodInfo = DOM.FiledAttirbute (or something similar).  It requires speding too much time in the debugger's immediate window trying to ferret this stuff out.  With Dynamic it looks like we will immensly ease this problem.  Thanks again.