我已经了解到静态作用域是唯一理智的做事方式,而动态作用域是魔鬼的工具,而且只是由于解释器/编译器的不良实现.
然后我从Common Lisp vs. Scheme文章中看到了这个片段:
Both Lexically and Dynamically Lexical scope only, per the standard.
scoped special vars. Common Dynamically scoped vars are provided
Lisp just wins on this point. by some implementations as an extension
but code using them is not portable.
(I have heard the arguments about whether Dynamic scoping
is or is not a Bad Idea in the first place. I don't care.
I'm just noting that you can do things with it that you
can't easily do without it.)
为什么Common Lisp"只是在这一点上获胜"？使用动态范围更容易做些什么？我真的无法证明曾经需要它/把它视为一件好事.
与其他一切一样,Dynamic Scoping仅仅是一种工具.使用得当它可以使某些任务更容易.使用不当可能会导致错误和头痛.
我当然可以看到它的一些用途.可以消除将变量传递给某些函数的需要.
例如,我可能会在程序开头设置显示,并且每个图形操作都只是假设显示.
如果我想在该显示内部设置一个窗口,那么我可以将该窗口"添加"到另外指定显示的变量堆栈,并且在此状态下执行的任何图形操作将转到窗口而不是显示为整个.
这是一个人为的例子,可以通过将参数传递给函数来同样做得很好,但是当你看到一些代码时,这种任务生成你会意识到全局变量真的是一个更容易的方法,动态范围给你一个全局变量的很多理智与功能参数的灵活性.
-亚当
动态范围的主要风险是意外后果.动态范围使得范围遵循运行时堆栈,这意味着范围中的符号集要大得多,并且在任何符号使用时都不明显.动态范围的变量很像全局变量,只有每个变量可能有多个版本,只有最新的定义可见,隐藏所有其他变量.
动态范围,只要它很有用,它对于需要对运行时堆栈敏感的行为很有用.例如(一般来说,不是特定于Lisp或变体):
异常处理 - 最常见的catch块是发生异常时"在范围内"的块
安全性 - 基于.NET代码的安全性根据调用它的代码决定某些特权API的可访问性.
依赖于它用于其他用途的问题在于它创建了隐含的依赖关系并且在词法上遥远的代码片段之间进行耦合.通过这种方式,它也类似于全局变量,只是它可能更糟(由于动态重写的定义).
动态作用域在某些特定于域的语言中很有用.特别是,它可以用于样式表语言.我的经验来自GNU TeXmacs样式表语言.
在这种语言中,显示参数存储在动态范围的变量中.这些变量会影响其范围内每个原子的渲染,包括由范围中调用的函数生成的原子.
除了其他方面,还使用TeXmacs中的动态范围来标记交叉引用.用于交叉引用的锚点从其环境中获取其标签.例如,公式块中包含的锚将使用公式编号作为标签,而不是位于公式后面的锚的节号.
想想看,unix环境变量也是动态范围的变量.尽管内部范围不能改变外部范围中变量的值.
正如Barry Kelly所指出的,动态范围也可用于实现关注调用范围的语言功能,例如异常处理或依赖于上下文的权限处理.在存在连续的情况下,可以输入和退出范围,而无需遍历调用堆栈.
动态范围允许定义上下文函数.从这个意义上讲,它与现代框架中的依赖注入非常相似.(例如,考虑使用依赖项注入定义注释Java类以允许对各种引用进行透明初始化.(参见spring或JPA等))
显然,动态作用域对给定函数的调用站点的运行时特性做出了某些假设,这些假设在编译(或设计)时无法得到保证.再次,按照现代(Java)框架组件的示例,如果您在容器的受控(运行时)环境之外实例化这样的类,则很可能该类将无法在其所需的依赖项下运行将不会被初始化(也称为注入).
但同样显而易见的是,组件系统(仅作为一个例子)明显受益于动态绑定机制.依赖注入是实现这一目标的框架级手段.动态范围是一种语言级别的手段.
京公网安备 11010802040832号 | 京ICP备19059560号-6 