Objective-J は、ブラウザー上で直接 JavaScript にコンパイル/変換されます。(これは、GWT が Java に対して行うように、サーバー上でこれを行うのとは対照的です。) このアプローチは、Objective-J 以外の言語で実装されていますか?
4 に答える
14
CoffeeScriptコンパイラは、CoffeeScriptをECMAScriptにコンパイルします。CoffeeScriptコンパイラはそれ自体がCoffeeScriptで記述されているため、ECMAScriptにコンパイルして、ブラウザで実行できます。要素をサポートするために必要な<script type='text/coffeescript'>要素は、標準のCoffeeScriptコンパイラにすでに含まれています。
一般に、どの言語もECMAScriptにコンパイルでき、必要なのはコンパイラーだけです。また、任意の言語をECMAScriptにコンパイルできるため、任意のコンパイラーをECMAScriptにコンパイルできます。必要なのは、コンパイラーが記述されている言語のコンパイラーだけです。
これは、ブラウザ内で言語をコンパイルする可能性の組み合わせ爆発につながります。
たとえば、楽しみのために高級言語を対象とするCコンパイラを作成するこの人がいます。彼は、CをJava、Perl、Common Lisp、Lua、またはECMAScriptにコンパイルするコンパイラを持っています。したがって、そのコンパイラを使用して、Cで記述された他のコンパイラをECMAScriptにコンパイルできます。そして、ほとんどの言語には、Cで書かれたコンパイラがどこかにあります。
手がかりはCで書かれています。手がかりはCをECMAScriptにコンパイルします。エルゴ、Clueを使用してClueをECMAScriptにコンパイルできます。次に、ブラウザでClueを実行して、CをECMAScriptにオンザフライでコンパイルできます。<script type='text/c'>、 誰でも？（楽しい考え：node.jsはCで書かれています。うーん…）
さらに深刻なことに、ECMAScriptにコンパイルする理由は一般的に3つあります。
- 再利用
- 安全性
- 表現度
別の言語で書かれた既存のコード（または別の言語の既存の知識）を単に再利用したい場合は、クライアントでのコンパイル/解釈はあまり意味がありません。<script>コードまたはコーダーは、とにかく要素を使用できることを期待していません。このカテゴリには、GWTやVoltaなどが含まれます。
（型）安全性が目標である場合、クライアントでのコンパイル/解釈は単純に機能しません。コンパイラーを制御しない場合、安全性をどのように保証できますか？そのため、Ur / Web、Links、Flapjax、Haxe、Cajaなどがサーバー上でコードをコンパイルします。これらは、静的型付けまたは緊密な統合、あるいはその両方によって安全性を保証します。（緊密な統合とは、バックエンド、フロントエンド、アプリが緊密に接続されていることを意味します。たとえば、データ構造を一度指定してから、対応するSQL、ECMAScript、HTMLフォームをその単一のソースから生成して、すべてが一致することを確認します。これがサーバーでの処理を必要とする理由。）
ただし、表現度に重点を置いたものは、ECMAScriptの代わりに、つまり<script>要素の内部で使用されることを期待しているため、クライアントで実行されるインタープリターやコンパイラーが付属していることがよくあります。CoffeeScript、Objective-J、Clamatoはこのカテゴリに分類されます。
于 2010-10-09T02:18:06.293 に答える
7
于 2011-01-07T13:01:14.933 に答える
4
Ruby のような言語を JavaScript にコンパイルする例を次に示します。コンパイルはブラウザで実行できます。
于 2010-10-09T01:30:43.593 に答える