Dynamic type support in C#? Sweet!
Ok, so it's just in the planning stages, but you may have run across Charlie Calvert's recent blog post about supporting dynamic (aka runtime) lookup for methods/properties/etc which would avoid having to deal with that ghastly beastie that is reflection (even though I'll admit the reflection API's are probably about as good as they can be given the nature of what they're doing).
https://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx
Dynamic Lookup
The next version of Visual Studio will provide a common infrastructure that will enable all .NET languages, including C#, to optionally resolve names in a program at runtime instead of compile time. We call this technology dynamic lookup.
Work on support for dynamic lookup was begun in the CLR, but soon became part of the Dynamic Language Runtime, or DLR. The DLR provides the infrastructure on which a common set of dynamic tools can be built. For instance, the DLR provides the infrastructure for both IronRuby and IronPython. It will be the infrastructure on which the C# team implements dynamic lookup .
Support for dynamic lookup is already available in Visual Basic for .NET, where it is often known as “late binding”. The new release of .NET will provide C# developers with similar functionality, while at the same time providing a shared infrastructure for runtime name resolution across all .NET languages, including VB.
I went ahead and added my own comment on implementation, but would love to see others chime in as well. Here's my comment, just to make this blog post longer than it needs to be.
Love the idea, but the dynamic keyword is indeed a bit limiting - since it's most logically tied to an instance, the "this is dynamic" magic should be tied to an instance/variable instead of a scope.
What Andrew Davey said about IQuackFu from Boo is good, but IMHO the easier and more powerful approach is also from Boo - the "duck" type (https://boo.codehaus.org/Duck+Typing), which you declare a variable as and then the compiler knows that it's a dynamic type. Then you can pass "duck" objects around without having to deal with the dynamic keyword. Then tools (like the debugger) also know the instance is "special" and interact with it as such.
Instead of duck, though, perhaps System.Dynamic or similar, since it probably makes sense to have it represented in the BCL since you may want to string some static methods off of the type (System.Dynamic) that helps runtime interaction with such objects, like easier-than-reflection inspection of methods/properties/etc, or Ruby's "reopen this instance/the entire class" support, or whatever.
Back to the IQuackFu/IDynamicDispatch idea - as long as the compiler implements it as a fallback so "regular" method calls that are implemented by the type keep working as normal, then that's fine with me - it's effectively Ruby's method_missing at that point, which would be useful to have in some situations.
The combination of the two gives you both fully-dynamic instances (with the duck typing aka System.Dynamic) and partially-static, partially-dynamic (with IQuackFu aka IDynamicDispatcher), so you can choose what works best for you.
The idea is great, but I really fear the dispatch keyword+scope approach would make it less useful (read: more cumbersome) to interact with.
Comments
Anonymous
February 20, 2008
VB6 and VB.Net developers know this feature: "Late Binding" and C# developers have often ridiculedAnonymous
February 21, 2008
You've been kicked (a good thing) - Trackback from DotNetKicks.com