jhe*_*dus 12 java scala javafx scalafx
我正在尝试使用JavaFX和Scala实现一个带有一些思维导图功能的简单笔记组织器.
我试图决定是否应该直接从Scala或通过ScalaFX调用JavaFX代码?我不知道是否值得学习ScalaFX,从Scala代码直接调用JavaFX会不会更简单?
该官方网站ScalaFX提到ScalaFX的4个好处:
1)自然语言绑定表达
- 这很好,但我并没有真正计划使用那么多的绑定(我打算使用EventBus进行inter-gui-component事件和一些gui-component事件的绑定).
2)量身定制的动画语法
- 我不打算在我的项目中使用动画.
3)完全类型安全的API
这似乎是一个微不足道的点......类型安全是Java开发人员一直拥有的(并且通常认为是理所当然的),而其他脚本语言的开发人员则没有(并且因此在不知不觉中遭受运行时错误).但是,如果您正在开发在部署后无法出现意外运行时错误和错误的应用程序,则这是一项关键功能.
一个好的编译器将能够通过比较预期和实际类型来获取许多常见的编码错误,并且一个优秀的编译器(如Scala)将自动为您推断类型,因此您不必在整个代码中重复这些错误.
ScalaFX使用类似脚本的DSL语法获得两全其美,您很少需要显式地键入对象,Scala编译器具有强大的类型安全性,可以推断并检查每个表达式和API调用的类型.这意味着花费更少的时间来调试奇怪的代码错误和拼写错误,以及更高质量的代码!
- 这看起来很有趣!但我的问题是:我怀疑直接从Scala调用JavaFX给了我与通过ScalaFX调用JavaFX相同的类型安全保证吗?我不知道.
4)无缝JavaFX/ScalaFX互操作性:
- 如果我直接从Scala调用JavaFX,那么与通过ScalaFX调用JavaFX相比,我不必担心互操作性问题.
综上所述:
似乎第3点是唯一可以在我的简单项目中给我一些我关心的好处,但我不知道他们真正在谈论什么类型的安全性?
为什么通过ScalaFX调用JavaFX比直接从Scala调用类型安全更好?如果我们使用ScalaFX而不是Scala直接访问,我们会获得什么样的额外类型安全优势?我问这个是因为我无法想象ScalaFX可以提供什么样的额外类型安全性?
所以,换句话说,我知道ScalaFX对于绑定来说是一个很好的语法糖,但是它提供了更多吗?如果我可以在没有(非常好的)合成糖的情况下生活,我真的应该使用它吗?
除了糖之外还有什么东西可以使用这个包装层(ScalaFX)来引入额外的复杂性(和bug的来源)吗?
请注意,我非常感谢ScalaFX创作者的工作!我只是要求这些问题能够做出更明智的决定.
Oli*_*low 10
ScalaFX是用于处理JavaFX 的DSL.提供,你所谓的"语法糖"是DSL 的主要目的.
(DSL传统上也将主机语言的范围限制在目标域,但通常不希望Scala DSL.)
现在,它是如何以及何时有用的,本身就是一场辩论,但这恰好是它所提供的一切.就个人而言,我总是更喜欢一种API,它可以让我更清楚地向同行和未来的自己传达我的意图,但这是每个团队和项目必须自己决定的事情.ScalaFX的绑定语法很棒,因为Properties和Bindings正在越来越多的后端(即使没有JavaFX GUI).
我认为ScalaFX广告类型安全的原因并不是因为它是ScalaFX本身的一个特殊功能,而是因为值得注意的是使用像ScalaFX这样的类似脚本的语言并利用平台的强大功能那就是Scala,仍然会给你类型安全性(对于新手和不熟悉Scala的人来说,这可能是违反直觉的).
我建议在你的情况下使用ScalaFX ,因为它听起来你正在开发一个小项目,主要关注通过JavaFx GUI提供的用户体验(我假设给出了你的描述).ScalaFX允许您在GUI上快速迭代.
在开始时不要担心开销,您的用例几乎不会是性能要求苛刻的应用程序.如果你确实需要担心性能,为什么要使用Scala;)?
ScalaFX 的最大缺点是每个JavaFX类型都需要用SFXDelegate 包装,如果你需要的某些类型没有被包装,或者将来某些东西被添加到JavaFX并且你需要等待ScalaFX将它包装在你之前,这很麻烦可以用它(这两个都是没有真正阻滞剂但正如第一,它是微不足道的包一个JavaFX类型(见ScalaFX维基),其次的JavaFX的发布周期是多比ScalaFX的慢.
归档时间: |
|
查看次数: |
2024 次 |
最近记录: |