.net - 在C#上下文中动态功能运行时的 future ？

因此，C#已经发展成为静态类型的语言，并且在利用.net框架开发Line of Business Applications方面占据了利基市场，而做得还不完美。

如今，很明显，在最近的过去，微软已经开始向其他基本范例迈进，直到最近，C#和.net才真正声称它们是该工具。

其中之一是DLR

好的语言多样性-很好，我在想，直到现在，如果我想利用该功能，当我用类编写业务实体时，似乎就不得不改变我的思维方式...这很酷，而且我都在学习新知识。但是在此之前，我要向受人尊敬的社区提出一些问题。现在为澄清起见，我对将DLR与CLR一起应用更加感兴趣。

因此，我们开始:

您认为DLR是一项可行的功能，需要从企业商业软件开发的角度来看待吗？意思是，C#确实需要C#作为一项功能来继续执行其工作吗？还是在那时切换到标准的动态类型语言更有意义？

用CLR和DLR开发和编写代码的结合在业务适用性方面的优势在哪里？具体的例子对我来说是最有值(value)的。

的好处。

现在，msdn这样说:
Provides Future Benefits of the DLR and .NET FrameworkLanguages implemented by using the DLR can benefit from future DLR and .NET Framework improvements. For example, if the .NET Framework releases a new version that has an improved garbage collector or faster assembly loading time, languages implemented by using the DLR immediately get the same benefit. If the DLR adds optimizations such as better compilation, the performance also improves for all languages implemented by using the DLR.
好极了，但是究竟如何呢？如果仍然升级我的框架，我不会得到相同的结果吗？为什么我需要为此写DLR？

您能否发布代码示例以展示DLR比常规C#可以做得更好？

是否值得学习成为一名适销对路的.net工程师，还是只是说:“哦，我们比Ruby更好，公元前我们也可以做到，而且还可以做到更多”，这或多或少是一项过时的功能？

合并这两个或仅在应用程序中单独使用DLR会产生哪些开销。发展？

DLR可以与f＃一起使用吗？

问候。

最佳答案

可能需要澄清的是，DLR是位于CLR之上的API，它降低了实现动态键入语言功能的标准。您可以像IronPython，IronRuby，Clojure和其他语言来端到端使用它来实现您的语言。您可以像C#或VB一样使用它来获得动态调用站点缓存(搜索内联多态缓存以获取有关概念的常规信息)。因此，C#添加了'dynamic'关键字，它使用DLR的CallSites，活页夹，DynamicMetaObjects等来实现此语言功能。

是的，DLR是一种可行的功能，对于C#是有意义的。 C#落后于VB，用于COM互操作，无类型数据源(DB，XML等)，以及Web页面后的轻量级语法(例如button.text =“yo”)。当我喜欢一种语言时，发现它通常很有用，或者调动了我的才华，我喜欢尽可能多地使用该语言。除非我确实需要这样做，否则我不必通过使用多种语言来拼凑在一起并在解决方案中增加维护开销。 C#的“动态”功能使我能够以更轻松，更轻松的方式完成本来可以在C#中完成的工作，这当然意味着我不必借助纯动态的或可选的显式类型的语言来更轻松地编写代码。现在的情况。

如果您试图向语言或大型，丰富的系统中添加动态类型功能，则使用DLR开发代码将大放异彩。正如经常引用的那样，“任何足够复杂的程序都包含……Lisp的临时……实现。”如果您发现需要对数据或对象进行动态类型化访问，并在给定输入的情况下对某种操作的含义进行某种计算，并希望将该操作缓存起来，以便随后在程序中的该位置进行类似的计算，则DLR可以帮助您做到这一点以较低的成本。事实是，由于C#为您引入了“动态”功能，因此您甚至不需要在此级别使用DLR。但是，您可能希望在代表数据源的某些对象上实现IDynamicMetaObjectProvider，以便它们可以参与C#的动态调度调用站点执行的绑定(bind)操作。例如，如果XmlElement实现了IDMOP，那么您可以编写如下内容:
动态x = source.GetXmlElement(...);
…x.Customers [i] .Address.City ==“伊利”…

好处是针对本质上是动态变化的数据或对象编写的代码具有更高的可表达性，而不必表达复杂的中间类型声明并进行大量的o.G​​etBlahByName(“whatever”)调用。

您从DLR文档引用的段落是关于在DLR上构建的语言实现的。是的，当然，您的应用程序也能从中受益。问题的重点在于，例如，IronPython如何更快地运行，这不仅是因为DLR的出现，还因为CLR本身的工作确实间接改善了DLR上Iron Iron的实现。

除非您需要为您的语言或系统添加一些缓存的动态访问权限，否则不要费心学习DLR。大多数人不会以这种复杂程度进行编码。大多数人使用语言和框架，很少有人实现它们。

F#可以使用DLR，但是一个常见的误解是F#是一种动态语言。它不是。它严格是静态类型的，但并不是在所有情况下都明确地键入，这使人们感到困惑。由于大量使用类型推断和大量的空格，因此它在语法上看起来很轻巧。如果F#有一天决定像C#那样添加“动态”类型模型，那么使用DLR使其易于实现并与C#互操作，.NET上的动态语言，动态库和框架是有意义的。 ， 等等。

账单

关于.net - 在C#上下文中动态功能运行时的 future ？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4891615/