A simple sample for C# 4.0 ‘dynamic’ feature
Earlier I posted some code to start Visual Studio using C# 3.0:
using System;
using EnvDTE;
class Program
{
static void Main(string[] args)
{
Type visualStudioType = Type.GetTypeFromProgID("VisualStudio.DTE.9.0");
DTE dte = Activator.CreateInstance(visualStudioType) as DTE;
dte.MainWindow.Visible = true;
}
}
Now here’s the code that does the same in C# 4.0:
using System;
class Program
{
static void Main(string[] args)
{
Type visualStudioType = Type.GetTypeFromProgID("VisualStudio.DTE.10.0");
dynamic dte = Activator.CreateInstance(visualStudioType);
dte.MainWindow.Visible = true;
}
}
At first, it looks the same, but:
- Referencing EnvDTE.dll is not required anymore – you also don’t need using EnvDTE – don’t need to reference anything!
- You declare the ‘dte’ variable to be weakly typed with the new dynamic contextual keyword
- You don’t have to cast the instance returned by Activator.CreateInstance
- You don’t get IntelliSense as you type in the last line
- The calls to dte are resolved and dispatched at runtime
It’s a trade-off, but I still view dynamic as yet another useful tool in the rich C# programmer’s toolbox to choose from.
Comments
Anonymous
May 01, 2009
The comment has been removedAnonymous
May 01, 2009
>I'd like to think there will be some kind of safeguard to prevent that, but I won't hold my breath. What kind of safeguard would you expect? The whole point of late binding is that it's done after the compiler's already had its chance to ensure correctness. If that level of type safety is a requirement for to you, there's not really anything in C# 4.0 stopping you from building against an Interop DLL the way you do today.Anonymous
May 01, 2009
The comment has been removedAnonymous
May 02, 2009
This is good for simple script, but I do not feel this being suitable for an application consisting of more than one file. Take IntelliSense -- I may know what the methods of DTE are, but the second solution will require all developers in my team to know it as well. While with IntelliSense they learn it as they need. Or just simple maintainability -- if we upgrade to a later version of COM interface, what will break? Add X hours of manual testing and you will know.Anonymous
May 03, 2009
Kirill Osenkov has posted a simple example showing the code using forthcoming "dynamic" keywordAnonymous
May 03, 2009
While I like the trend of bringing support for dynamically evaluated types, I agree with comments above that in this particular case the trade-off can feel too big for many developers. We don't easily give up strong types. I tried to sketch how C# can support both: dynamic types with IntelliSense support in the cases when it can be retrieved at compile time. Here's what I got: http://bloggingabout.net/blogs/vagif/archive/2009/05/03/intellisense-and-dynamic.aspxAnonymous
May 05, 2009
This makes me sad. This was a step in the wrong direction for C#. It was bad with VB/VBA called it "Variant", and it's still a horrible idea now. Not trying to shoot the messenger, I'm just sayin..Anonymous
May 07, 2009
Kirill, what about the perf comparison of both?Anonymous
May 09, 2009
The comment has been removedAnonymous
June 08, 2009
This example is probably a bad example of the usefulness of dynamic as it doesn't solve anything that couldn't otherwise be solved relatively easily in regular ol' .NET. Save a cast? No need to import a library...I dunno; those two don't sell me on the usefulness of dynamic. On the other hand, it does make possible one scenario that required quite a bit of code to resolve: double dispatch. See: http://www.charliedigital.com/PermaLink,guid,e65b5c84-b54d-468a-81bf-211e35d8fb5c.aspx And then see: http://www.charliedigital.com/PermaLink,guid,93e4f51f-043f-49b6-815a-f3dd1e2ad7b3.aspxAnonymous
June 08, 2009
Hi all, I agree that this is probably not the best example for dynamic. Also, Charles, the double-dispath thing is extremely cool! Thanks, Kirill