Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>It might be worth clarifying that the DLR is an API layered on top of the CLR to lower the bar for implementing dynamic typing language features. You can use it end-to-end as IronPython, IronRuby, Clojure, and other languages do to implement your language. You can use it piece-meal like C# or VB to just get dynamic call site caching (search for inline polymorphic caching for general info on the concepts). So, C# adding the 'dynamic' keyword, and it uses the DLR's CallSites, binders, DynamicMetaObjects, etc., to implement this language feature.</p> <p>Yes, the DLR is a viable feature and makes sense for C#. C# was behind VB for COM interop, untyped data sources (DB, XML, etc.), and for lighter weight syntax behind web pages (e.g., button.text = "yo"). When I love a language, find it generally useful, or have tuned my prowess in it, I like to use that language as much as possible. I don't want to have to cobble together and create maintenance overhead in my solution by using multiple languages unless I really need to do that. C#'s 'dynamic' lets me do things I could already do in C# in a much easier and tastier way, and it certainly means I don't have to resort to a purely dynamic or optionally explicitly typed language for easier to write code in many more situations now.</p> <p>Developing code with the DLR shines if you are trying to add dynamic type features to a language or big, rich system. As is often quoted, "any sufficiently complicated … program contains an ad hoc … implementation of … Lisp." If you're finding you need some dynamically typed access to data or objects, with some computation of what an operation means given some inputs and want to cache that action for subsequent similar computations at that location in the program, the DLR helps you do that in a lower cost way. The thing is, you may not even need to use the DLR at this level since C# has introduced 'dynamic' for you. However, you may want to implement IDynamicMetaObjectProvider on some objects representing your data sources so that they can participate in the binding operations that C#'s dynamic dispatch callsites perform. An example of this would be if XmlElement implemented IDMOP so that you could write something like: dynamic x = source.GetXmlElement(…); … x.Customers[i].Address.City == "Erie" …</p> <p>The benefits are a higher degree of expressability in the code written against the data or objects that are inherently dynamic by their nature, rather than having to express complicated intermediate type declarations and do a lot of o.GetBlahByName("whatever") calls.</p> <p>The paragraph you quoted from the DLR docs is about language implemantations build on the DLR. Yes of course your apps get the benefits too. The point was more about how, for example, IronPython got way faster not just because of the advent of the DLR but because the CLR itself did work that indirectly improved the IronPython implementation on the DLR.</p> <p>Don't bother learning the DLR unless you need to add some cached dynamic access to your language or system. Most people do not code at this level of complexity. Most people use languages and frameworks, few people implement them.</p> <p>F# could use the DLR, but a common misconception is that F# is a dynamic language. It is not. It is strictly statically typed, but it is not explicitly typed in all cases, which is what confuses people. It looks lightweight syntactically due to heavy use of type inferencing and significant whitespace. If F# were one day to decide to add a 'dynamic' type model like C# did, then it would make sense for it to use the DLR for ease of implementation and for interop with C#, dynamic languages on .NET, dynamic libraries and frameworks, etc.</p> <p>Bill</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload