代码之家 › 专栏 › 技术社区 › James Black

用动态语言编写超出规范允许范围的程序

dynamic-languages specifications

0

James Black · 技术社区 · 16 年前

当我读到博宾斯的答案时,我的思维受到了这个问题的影响: A question about JavaScript's slice and splice methods

基本思想是 splice ,在Javascript中,被指定仅在某些情况下使用,但是,它可以在其他情况下使用,并且该语言无法阻止它,因为该语言的设计非常灵活。

除非有人通读了规范,并决定遵守它,否则我相当肯定会有很多这样的违规行为发生。

这是一个问题,还是编写这种灵活语言的自然延伸?或者我们应该期待像JSLint这样的工具帮助规范制定者吗?

我喜欢这个问题的一个答案,即python的实现就是规范。我很好奇,对于这些类型的语言来说,这是否更接近事实,基本上,如果语言允许您做一些事情,那么它就在规范中。 Is there a Python language specification?

在阅读了一些评论之后,我想我应该检查规范中的拼接方法,这是我在第104页底部发现的, http://www.mozilla.org/js/language/E262-3.pdf 因此,我似乎可以在不违反规范的情况下在孩子的数组上使用剪接。我只是不希望人们陷入我的例子中,但希望能考虑这个问题。

    The splice function is intentionally generic; it does not require that its this value be an Array object. 
Therefore it can be transferred to other kinds of objects for use as a method. Whether the splice function 
can be applied successfully to a host object is implementation-dependent.

更新2: 我对javascript不感兴趣,但对语言灵活性和规范感兴趣。例如,我希望Java规范指定您不能将代码放入接口,但使用AspectJ我经常这样做。这可能是一种违反,但是作者没有预测到AOP,并且该工具足够灵活,可以弯曲以适应这种使用,正如JVM对于Scala和Clojure也足够灵活一样。

4 回复 | 直到 9 年前

1

0

Breton 16 年前

任何高级语言设计的目标都应该是减少为了完成任务而需要编写的代码量,而不会太多地损害可读性。需要编写的代码越多,引入的bug就越多。限制型系统(如果设计不好的话)在最坏的情况下是一个普遍的谎言,在最好的情况下是一个过早的优化。我不认为过于严格的类型系统有助于编写正确的程序。原因是该类型只是一个断言,不一定基于证据。

2

1

Alex Martelli 16 年前

略微是这里的关键词。只有“契约式设计”——一种允许您明确说明前提、后置条件和不变量的语言,以及它们——可以帮助您对抗您的库的用户,以经验的方式发现库到底会让他们得到什么,并利用这些发现超越您的设计意图(可能会限制您未来更改设计或其实现的自由)。主流语言不支持“契约式设计”——埃菲尔是最接近这一点的语言,现在很少有人会称之为“主流”——大概是因为它的成本(大部分不可避免地是在运行时)似乎无法用它的优势来证明。”参数x必须是一个素数,“方法a必须在调用方法B之前被调用”,“方法D被调用后不能再调用方法C”等等——这些都是您需要考虑的典型约束类型喜欢

3

0

Tommy McGuire 16 年前

我不认为你的问题真的与动态和静态类型有多大关系。事实上,我可以看到两种情况:一方面,马丁·克莱顿提到了达夫的装置;这种用法在您第一次看到它时非常令人惊讶,但语言的语义明确允许这种用法。如果有一个标准,这种习惯用法可能会作为一个具体的例子出现在标准的后续版本中。这些都没有错,;事实上,它们可以(除非过度使用)极大地提高生产率。

另一种情况是对实现进行编程。这种情况将

4

0

atk 16 年前

在我看来,原来的问题有点不连贯。如果规范明确允许特定行为(如必须、可能、应该或应该),那么根据定义,任何允许/实现该行为的编译器/解释器都符合该语言。这似乎是OP在comments部分中提出的情况——JavaScript规范假定*表示所讨论的函数可以在不同的情况下使用,因此它是明确允许的。

另一方面,如果编译器/解释器实现或允许规范明确禁止的行为,那么根据定义,编译器/解释器在规范之外运行。

还有第三种情况,以及相关的定义良好的术语,用于规范未定义行为的情况:未定义。如果规范没有实际指定特定情况下的行为,那么该行为是未定义的,编译器/解释器可能会有意或无意地处理该行为。然后,开发人员有责任意识到该行为不是规范的一部分,并且,如果他/她选择利用该行为,开发人员的应用程序因此依赖于特定的实现。提供实现的解释器/编译器没有义务维护官方未定义的行为,除了向后兼容性和生产者可能做出的任何承诺。此外,语言规范的后续迭代可能会定义先前未定义的行为,使编译器/解释器(a)与新迭代不兼容,或(b)推出新补丁/版本以变得兼容,从而破坏旧版本。

*“大概”是因为我自己还没看过说明书。我同意上面的陈述。