0

動的型付け言語の成長に伴い、柔軟性が向上するため、人々が仕様で許可されている以上のプログラムを作成する可能性が非常に高くなります。

ボビンスの回答: A question about JavaScript's slice and splice methodsを読んだとき、私の考えはこの質問の影響を受けました。

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

誰かが仕様を読み、それに従うことに決めない限り、そのような違反が数多く発生していることは確かです。

これは問題ですか、それともそのような柔軟な言語を書くことの自然な延長ですか? それとも、JSLint のようなツールが仕様の警察に役立つと期待すべきでしょうか?

この質問の中で、python の実装が仕様であるという 1 つの回答が気に入りました。それがこれらのタイプの言語の真実に実際に近いかどうか、私は興味があります。基本的に、言語で何かを実行できる場合、それは仕様に含まれています。 Python 言語仕様はありますか?

アップデート：

いくつかのコメントを読んだ後、仕様の splice メソッドを確認しようと思いました。これが、104 ページの下部にあるhttp://www.mozilla.org/js/language/E262-3 で見つけたものです。 pdfであるため、仕様に違反することなく子の配列で splice を使用できるようです。私の例で人々が行き詰まることを望んでいませんが、うまくいけば、質問を検討してください。

    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

4 に答える 4

1

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

于 2009-11-28T01:46:42.633 に答える
0

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

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

まだ3番目のシナリオがあり、仕様で動作が定義されていない状況に関連する、明確に定義された用語、未定義があります。仕様が特定の状況での動作を実際に指定していない場合、その動作は未定義であり、コンパイラー/インタープリターによって意図的または意図せずに処理される可能性があります。その場合、動作が仕様の一部ではないことを認識するのは開発者の責任であり、動作を活用することを選択した場合、開発者のアプリケーションは特定の実装に依存します。その実装を提供するインタプリタ/コンパイラは、下位互換性およびプロデューサが行う可能性のあるコミットメントを超えて、公式に定義されていない動作を維持する義務を負いません。さらに、

*私自身、スペックを見たことがないので「たぶん」。私は上記の発言を通ります。

于 2009-11-28T01:39:09.690 に答える
0

あなたの質問は、動的型付けと静的型付けとはあまり関係がないと思います。実際、私は 2 つのケースを見ることができます。一方では、マーティン・クレイトンが言及したダフの装置のようなものがあります。その使用法は、初めて見たときは非常に驚くべきものですが、言語のセマンティクスによって明示的に許可されています。標準がある場合、その種のイディオムは、具体的な例として標準の後の版に表示される場合があります。これらには何の問題もありません。実際、(使いすぎない限り) 生産性を大幅に向上させることができます。

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

于 2009-11-28T01:54:40.877 に答える
0

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

高水準言語設計の目標は、読みやすさをあまり損なうことなく、作業を完了するために記述する必要があるコードの量を減らすことです。書かなければならないコードが多ければ多いほど、より多くのバグが導入されます。制限型システムは、（適切に設計されていない場合）、最悪の場合は蔓延する嘘、せいぜい時期尚早の最適化になる可能性があります。過度に制限的な型システムが正しいプログラムを書くのに役立つとは思いません。その理由は、型が単なるアサーションであり、必ずしも証拠に基づいているとは限らないためです。

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

于 2009-11-28T01:23:51.827 に答える