‘Stupid’ Question 33: Why was the DLR and Dynamic keyword introduced in Net?
From Wiki: “Plastic dynamism”, a term used by the Italian futurist art movement to describe a concept pertaining to an object’s motion, both intrinsic and relative to its environment. Painting by Umberto Boccioni
I went to a user group meeting yesterday with Swenug and listened to Filip Ekberg talk about Roslyn, reflection and Dynamic. I’ve been using reflection and dynamic, the latter one more the last few months as we worked with SimpleData (“A light-weight, dynamic data access component for C# 4.0”). First time I ever looked at dynamic was two months into programming when I missed the last buss home and decided to watch some random Pluralsight tutorial while waiting. What I remember was thinking, ‘cool stuff, but doesn’t fit in with the language?’. I didn’t know anything about dynamic languages at the time, and I forgot that thought until yesterday, when I asked this at the UG. I got the reply ‘Ruby envy’ – and although a funny comment, I would still like to know, why was the dynamic keyword and the DLR added to .Net?
Lucky me I found a great article on MSDN by Alexandra Rusina that answered my question:
DLR was introduced to allow static typed languages, such as C# to work with languages such as ruby (hence the Ruby-envy comment) and python, and to add dynamic behavior to the language.
I get the first one, interoperability (you will find many examples with Microsoft Office), but it is the second reason that I’m most curious about. Do we need dynamic behavior in a static language and in your opinion – does it fit in?
Comments
I was under the impression that it was added predominantly to simplify COM interop. Some sources: http://msdn.microsoft.com/en-us/magazine/ff714583.aspx http://www.devx.com/dotnet/Article/42590 http://msdn.microsoft.com/en-us/library/dd264736.aspx http://www.codeproject.com/Tips/143694/Get-rid-of-COM-Interop-DLL-by-using-the-new-C-4-dy
Yes and no! Most of the time we want to stay with static typing but there are always things out of our control. Like parsing XML or calling into COM where we previously had to resort to magic strings or clunky APIs that wouldn't provide any typesafety anyway. See this example for how COM becomes simpler: http://www.devx.com/dotnet/Article/42590 Then there are things like the ViewBag in asp.net mvc which is much nicer to use now that we have dynamic even though I would personally strongly argue for using typed views instead. So we don't really need it and we shouldn't abuse it. Use it to make situations where we have no type safety anyway more developer friendly.
That seems to be one of the main use-scenarios- and goes under reason one - interoperability An interesting article: http://msdn.microsoft.com/en-us/magazine/ff714583.aspx
LOL we edited our comments at the same time and added the same link :D
"dynamic" objects are, for the most part, just a syntax around a Dictionary. We've had those since .NET v1.0 (albeit in a non-generic form), so one could argue that they are necessary. But, as with many things in programming, the slick syntax masks a lot of complexity, which you might want to be aware when designing & coding.
+1 Mikael Eliasson, +1 James I find dynamic a bit of a mixed blessing. the following is my use of them for day to day use. performance & simplicity for co/contravariance can also be a reasonable use. using delegates to convert between types can be very performant and more flexible than using reflection, but that comes at the cost of the code becoming more complex to maintain and less clear to read. using dynamic keyword to help, while it's not as performant as the delegate based techniques, it is still reasonable in performance and certainly clearer. there is the obvious issue though that this should be guarded well as using this does weaken the typing with a pinch point at its use, so should be used carefully and sparingly in order to maintain the benefit of the typing from the compiler. if you make use of code contracts, then there are obvious issues in that they are mutally exclusive technologies, and so would loose the compiler benefits there. There are assumptions that can be applied to the code contracts, and if you've maintained your code appropriately these restrictions needn't be too much of a problem. they are not escaping the type system (in the way that nulls can be - but dont get me started on the lack of a BCL type for Unit ;-) ), they are just loosening it; too loose and you stop the compiler being able to help you. I presume we are all in agreement that that's not good, and on the whole is seen as sloppy coding.
Last modified on 2012-08-28