仕様で許可されている範囲を超える動的言語でプログラムを作成する

Question

動的に型付けされた言語の成長により、柔軟性が増すため、仕様で許可されている範囲を超えるプログラムを作成する可能性が非常に高くなります。

bobinceで答えを読んだとき、私の考えはこの質問の影響を受けました。 JavaScriptのスライスおよびスプライスメソッドに関する質問

基本的な考え方は、JavaScriptの splice は特定の状況でのみ使用されるように指定されているが、他の状況では使用でき、言語が停止するためにできることは何もないということです。言語は非常に柔軟に設計されているため。

誰かが仕様書を読み、それを順守することを決定しない限り、そのような違反が多く発生していることはかなり確信しています。

これは問題なのでしょうか、それともそのような柔軟な言語の自然な拡張なのでしょうか？それとも、JSLintのようなツールが仕様ポリシングを支援することを期待すべきですか？

この質問には、Pythonの実装が仕様であるという答えが1つありました。それがこれらのタイプの言語の実際により近いかどうか、基本的には言語があなたに何かをすることを許すならそれが仕様にあるかどうか、私は興味があります。 Python言語仕様はありますか

更新：

いくつかのコメントを読んだ後、仕様のspliceメソッドをチェックすると思ったのですが、これがpg 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を使用して頻繁に行います。これはおそらく違反ですが、JVMがScalaとClojureに対しても十分に柔軟であるように、ライターはAOPを予測せず、ツールはこの用途に柔軟に対応できるほど柔軟でした。

Answer 1

この種の柔軟性は、メソッドが人工的な外部の「タイプ」ではなく、明確に定義されたインターフェースを中心に設計されている限り、利点であると思います。メタデータ。ほとんどの配列関数は、lengthプロパティを持つオブジェクトのみを想定しています。それらをすべて多くの異なる種類のオブジェクトに一般的に適用できるという事実は、コードの再利用にとっては朗報です。

高レベルの言語設計の目標は、読みやすさをあまり損なわずに、物事を成し遂げるために書く必要があるコードの量を減らすことです。より多くのコードを書かなければならないほど、より多くのバグが導入されます。制限型システムは、（うまく設計されていない場合でも）最悪の場合は広範囲にわたる嘘であり、せいぜい時期尚早な最適化です。過度に制限的な型システムが正しいプログラムの作成を支援するとは思わない。その理由は、タイプが単なる主張にすぎず、必ずしも証拠に基づいているわけではないからです。

対照的に、配列メソッドは入力値を調べて、機能を実行するために必要なものがあるかどうかを判断します。これはアヒルのタイピングであり、これはより科学的で「正しい」ものであり、より再利用可能なコードになると思います。論文が順番に揃っていないため、入力を拒否するメソッドは望ましくありません。それは共産主義です。

Answer 2

言語が静的に型付けされているか動的に型付けされているかは、本当にここでの問題のほんの一部です。静的に型付けされたものは、コードが仕様を強制するのをわずかに容易にするかもしれませんが、周辺がキーワードですここに。 「契約による設計」のみ-前提条件、事後条件、および不変条件を明示的に記述し、それらを強制することを可能にする言語-ライブラリのユーザーが、ライブラリが逃げることができるものを経験的に発見して、これらの発見の利点は、設計意図を超えることです（おそらく、設計またはその実装を変更する際の将来の自由を制限します）。そして、「契約による設計」主流言語ではサポートされていません-エッフェルがそれに最も近く、「主流」と呼ぶ人はほとんどいません。最近-おそらく、そのコスト（ほとんどの場合、必然的に、実行時に）がその利点によって正当化されないように見えるためです。 「引数xは素数でなければなりません」、「メソッドBを呼び出す前にメソッドAを事前に呼び出しておく必要があります」、「メソッドDが呼び出されるとメソッドCを呼び出すことはできません」など述べる の典型的な種類の制約（そして、かなりのプログラミング時間とエネルギーのチェックを自分で行う必要なしに暗黙的に実施している）は、フレームワークにふさわしくありません。静的に型付けされた言語のコンパイラが実行できる小さなコンテキスト。

Answer 3

あなたの質問は、動的タイピングと静的タイピングに本当に関係があるとは思いません。本当に、私は2つのケースを見ることができます：一方で、マーティン・クレイトンが言及したダフのデバイスのようなものがあります。その使用法は、初めて見たときは非常に驚くべきことですが、言語のセマンティクスによって明示的に許可されています。標準がある場合、その種のイディオムは、特定の例として標準の後のエディションに表示される場合があります。これらには何の問題もありません。実際、（過度に使用されない限り）生産性を大幅に向上させることができます。

もう1つのケースは、実装へのプログラミングの場合です。このようなケースは、標準の無知、標準の欠如、単一の実装、またはさまざまなセマンティクスを持つ複数の実装のいずれかから生じる実際の不正使用です。 問題は、この方法で記述されたコードは、最適化または機能の追加が主要なアプリケーションを破壊する恐れがあるため、せいぜい実装間で移植性がなく、最悪の場合、言語の将来の開発を制限することです。

Answer 4

私にとっては、元の質問は少しだけ非継者のようです。仕様が明示的に特定の動作を許可する場合（MUST、MAY、SHALL、またはSHOULD）、動作を許可/実装するコンパイラ/インタープリターはすべて、定義により言語に準拠します。これはOPがコメントセクションで提案した状況のようです-JavaScript仕様*は、問題の関数はさまざまな状況で使用される可能性があるため、明示的に許可されていると述べています。

一方、コンパイラ/インタープリターが仕様で明示的に禁止されている動作を実装または許可する場合、コンパイラ/インタープリターは定義により仕様外で動作します。

まだ、3番目のシナリオと、関連する明確に定義された用語があります。これらの状況では、仕様で動作が定義されていません。未定義です。特定の状況で特定の動作が仕様で実際に指定されていない場合、その動作は未定義であり、コンパイラ/インタープリターによって意図的または意図せずに処理される可能性があります。その場合、振る舞いが仕様の一部ではなく、振る舞いを利用することを選択した場合、開発者のアプリケーションは特定の実装に依存することを認識するのは開発者の責任です。その実装を提供するインタープリター/コンパイラーは、後方互換性およびプロデューサーが行うコミットメントを超えて、公式に未定義の動作を維持する義務を負いません。さらに、言語仕様の以降の反復では、以前に未定義の動作を定義して、コンパイラ/インタープリターを（a）新しい反復に準拠しないようにするか、（b）新しいパッチ/バージョンを使用して準拠するようにします。古いバージョンの破壊。

*＆quot; supposedly＆quot ;;私自身、スペックを見ていないからです。上記の説明に従ってください。