12

JavaFX と Scala を使用して、マインド マッピング機能を備えたシンプルなノート オーガナイザーを実装しようとしています。

JavaFX コードを Scala から直接呼び出すか、ScalaFX 経由で呼び出すかを決定しようとしています。ScalaFX を学ぶ価値があるかどうかはわかりませんが、Scala コードから JavaFX を直接呼び出す方が簡単ではないでしょうか?

ScalaFXの公式サイトでは、ScalaFX の 4 つの利点について言及しています。

1) 自然言語バインド式

-それはいいことですが、バインディングをあまり使用する予定はありません (GUI コンポーネント間イベントには EventBus を使用し、GUI コンポーネント内イベントにはいくつかのバインディングを使用するつもりです)。

2) カスタマイズされたアニメーション構文

-プロジェクトでアニメーションを使用する予定はありません。

3) 完全なタイプセーフ API

これは取るに足らない点のように思えるかもしれません… 型の安全性は、Java 開発者が常に持っていたもの (そして多くの場合、当たり前のことだと思っています) であり、他のスクリプト言語の開発者はそれがなくても生きています (その結果、無意識のうちに実行時エラーに悩まされています)。ただし、展開後に予期しないランタイム エラーやバグが発生しないアプリケーションを開発している場合、これは重要な機能です。

優れたコンパイラは、予想される型と実際の型を比較す​​ることで、多くの一般的なコーディングの間違いを見つけることができます。また、優れたコンパイラ (Scala など) は自動的に型を推測するので、コード全体でそれらを退屈に繰り返す必要はありません。

ScalaFX は、オブジェクトを明示的に型指定する必要がほとんどないスクリプトに似た DSL 構文と、すべての式と API 呼び出しの型を推測してチェックする Scala コンパイラの強力な型安全性により、両方の世界を最大限に活用します。これは、奇妙なコードのバグやスペルミスのデバッグに費やす時間を短縮し、すぐに高品質のコードを作成できることを意味します!

-これは面白そうですね！しかし、私の質問は次のとおりです。Scala から JavaFX を直接呼び出すと、ScalaFX を介して JavaFX を呼び出すのと同じタイプの安全性が保証されると思いますか? 知らない。

4) JavaFX/ScalaFX のシームレスな相互運用性:

-Scala から JavaFX を直接呼び出すと、ScalaFX 経由で JavaFX を呼び出す場合よりも、相互運用性の問題について心配する必要がなくなります。

要約すれば：

ポイント3は、単純なプロジェクトで私が気にかけている利点を私に与える唯一のもののようですが、彼らが実際に話しているタイプセーフの種類がわかりませんか?

型の安全性に関して、Scala から直接 JavaFX を呼び出すよりも、ScalaFX を介して JavaFX を呼び出すほうがよいのはなぜですか? Scala から直接アクセスする代わりに ScalaFX を使用すると、どのような追加の型安全性の利点が得られるでしょうか? ScalaFX がどのような種類の追加の型安全性を提供できるか本当に想像できないので、私はこれを尋ねています。

言い換えれば、ScalaFX がバインドのシンタックス シュガーとして優れていることは理解していますが、それ以上のものを提供しているのでしょうか? それが与える（非常に素晴らしい）シンタックシュガーなしで生きていけるなら、本当にそれを使うべきですか？

余分な複雑さ (およびバグの原因) を導入するこのラッパー層 (ScalaFX) を使用する価値のあるものは、砂糖以外にあるでしょうか?

ScalaFX の作成者の仕事に本当に感謝しています! より良い情報に基づいた決定を下せるようにするために、これらの質問をしているだけです。

4

2 に答える 2

10

ScalaFX は、JavaFX を操作するためのDSLです。DSLの主な目的は、「シンタックス シュガー」と呼ばれるものを提供することです。

(DSL は伝統的に、ホスト言語の範囲をターゲット ドメインに制限しますが、これは通常、Scala DSL には望ましくありません。)

さて、それがいつ、どのように役立つかは、それ自体が議論の余地がありますが、本質的にはそれが提供するすべてです. 個人的には、自分の意図を仲間や将来の自分にもっと明確に伝えることができる API を常に好みますが、それはすべてのチームとプロジェクトが自分で決定しなければならないことです。プロパティとバインディングがますます多くのバックエンドに導入されているため (JavaFX GUI がなくても)、ScalaFX のバインディング構文は素晴らしいものです。

ScalaFX が型安全性を宣伝している理由は、それが ScalaFX 自体の特別な機能だからではなく、ScalaFX のようにそのようなスクリプトのような合理的な言語を使用し、プラットフォームの力を活用していることが注目に値するからだと思います。それが Scala であり、型安全性を提供します(初心者や Scala に不慣れな人にとっては直感に反するかもしれません)。

あなたのケースではScalaFX を使用することをお勧めします。小さなプロジェクトに取り組んでいるように聞こえますが、これは主に JavaFx GUIを介して提供されるユーザー エクスペリエンスに重点を置いています(説明が与えられていると思います)。ScalaFX を使用すると、GUI 上ですばやくイテレートできます。

最初はオーバーヘッドについて心配する必要はありません。ユース ケースがパフォーマンスを必要とするアプリになることはほとんどありません。パフォーマンスについて心配する必要があるのなら、なぜ Scala を使用しているのですか ;)?

ScalaFXの最大の欠点は、すべての JavaFX 型をSFXDelegateでラップする必要があることです。これは、必要な型がラップされていない場合や、将来 JavaFX に何かが追加され、ScalaFX がそれをラップするのを待つ必要がある場合に面倒です。使用できます (どちらも本当のブロッカーではありませんが、第一に、JavaFX タイプをラップするのは簡単です ( ScalaFX Wiki を参照)。第二に、JavaFX のリリース サイクルはScalaFX のリリース サイクルよりもはるかに遅いです。

于 2014-03-30T14:01:23.290 に答える
4

純粋に実用的な観点から言えば、はるかに簡潔で読みやすいです。

Java と Scla のコードを比較して、これを自分で確認することをお勧めします。これには 2 つの優れた例があります。

  1. このコードは、ネイティブ Java とgithubの scalaFX の両方で利用できる本Pro JavaFXからの抜粋です(そのページに javafx コードへのリンクがあります)。

  2. また、 JavaFX-ensembleのコードとScalaFX-ensembleのコードを比較できます。繰り返しになりますが、ごちゃごちゃしていなくて読みやすいことがわかります。

@OJKrylow が指摘したように、JavaFX のすべてが移植されたわけではないため、いくつかの弱点があります。これは、すべてが scala に移植されていない scalafx-ensemble で明らかです。独自のコントロールを構築することを計画している場合は、それらを Java で記述してから、ScalaFX のラッパー オブジェクトを作成することをお勧めします。

しかし、あなたの場合のように小さなプログラムを書いている場合、これは理論的に複雑さを軽減するはずです。ただし、標準的な入門テキストがないということは、基本的に上記の 2 つの JavaFX リソースに頼って、それらが ScalaFX にどのように変換されるかを調べることになることを意味します (つまり、残念ながら、それ自体で実際に学習することはできません)。これが将来変わることを願っています。

于 2014-06-01T16:26:11.310 に答える