Haxeレビュー：Haxe4の機能と長所

公開: 2022-03-11

以前のHaxeレビューは、次のHaxe 4を見て終了しました。Haxe4の公式リリース（およびその後まもなく、2つのバグパッチリリース（バージョン4.0.1と4.0.2））で、新しいHaxeレビューの時間です。 。 この急成長しているプログラミング言語への最新の追加は何ですか？ Haxeプログラミング言語コミュニティはどこに向かっていますか？ Haxeゲームエンジンは今でも主力ですか？

Haxeレビュー：Haxe4の新機能

前回のメジャーリリースから3年以上の開発により、Haxeプログラミング言語のバージョン4は、マクロパフォーマンス、開発者エクスペリエンス、および構文を改善します。 その拡張機能のうち3つはまだ実験的なものと見なされていますが、強調する価値があります。新しいJVMバイトコードターゲット、インラインマークアップのサポート、およびnullの安全性チェックです。

Haxe4での実験的なJVMバイトコードコンパイルターゲット

Haxe 4の新しいJVMバイトコードターゲットは、主要なコンパイル手順を省くことにより、Haxeを介したJava開発をかなり効率的にします。Java独自のコンパイラ（ javac ）にHaxeのトランスパイラーのJavaソースコード出力をコンパイルさせる2番目の手順はありません。

Javaターゲット用に開発する場合の、新しい直接JVMターゲットと元のワークフローの比較。オリジナルはいくつかの.hxソースを取り、.javaソースを生成します。これは、実行可能な.jarファイルが最終的に生成される前に、Javaコンパイラ（JDKに依存）でコンパイルする必要があります。新しいターゲットを使用すると、開発者は.hxソースから実行可能な.jarファイルに直接移動できます。

Haxe 4でコンパイルするこの方法は、Java Developer Kit（JDK）への依存を完全に取り除き、将来実装されるインタラクティブなデバッグへの扉を開きます。

hxjavaの主流バージョンがHaxe4互換になるまで、基本的なセットアップでは、HaxeとHaxelibをインストールしてから、 haxelib install hxjava 4.0.0-alphaを実行します。 これで、開発フローは簡単になります。

 # transpile directly to JVM bytecode with Haxe (-D jvm would also work): haxe --main HelloWorld --java jar_output --define jvm # run JVM bytecode with Java: java -jar jar_output/HelloWorld.jar

直接JVMコンパイルがHaxe4でまだ実験的なステータスを持っていることを考えると、いくつかの注意点があります。

  • Androidに固有の問題がいくつかあります。
  • ランタイムのパフォーマンスは、最終的には間接的な方法よりも高速になるとしても、それほど良くはありません。

それでも、Javaベースのテクノロジーを活用する人にとっては正しい方向への注目すべき一歩です。

Haxe4での実験的なインラインマークアップのサポート

JSX、誰か？ Haxe 4はインラインマークアップを有効にし、開発者がたとえばHTMLをHaxeソースコード内に直接記述できるようにします。

 var dom = jsx( <div> <h1>Hello!</h1> <p>This is a paragraph.</p> </div> );

ここでのjsx()は静的マクロ関数である可能性があるため、これにより、プロジェクトは、マークアップが開発者が実装しようとしているXML風の仕様に準拠しているかどうかをコンパイル時にチェックできます。 XMLサポート自体がHaxeAPIに組み込まれているため、チェックではXml.parse()を利用できますが、基本的な「XML風」の解析可能性については、それも必要ありません。

 static macro function jsx(expr) { return switch expr.expr { case EMeta({name: ":markup"}, {expr: EConst(CString(s))}): macro $v{"XML MARKUP: " + s}; case _: throw new haxe.macro.Expr.Error("not an xml literal", expr.pos); } }

この機能の目的は、Haxeをゲーム開発バブルから追い出すのを助けることです（確かにそこでも使用されていますが）。 コンパイラレベルで実装されるのは十分に一般的であるため、上記のマクロでHaxe APIは必要ありませんが、特定のDSLをチェックすることは、コンパイラチームとコミュニティが理解する次の質問です。

Haxe4での実験的なヌルの安全性

1965年にnull参照が発明されて以来、nullの安全性の問題は、Haxeプログラミング言語のようなnull許容型の環境で開発者の悩みの種になっていることがよくあります。 Aleksandr Kuzmenkoは、GitHubが1,000万を超えるnullポインター参照エラーの修正をコミットしていると推定しています。

Haxe 4には、コンパイル時のnull安全マクロが組み込まれています。これは、特定の定義の直前に@:nullSafety行を含めることで有効にできます。 @:nullSafety(Loose) （デフォルト）および@:nullSafety(Strict)モードで提供され、必要に応じて@:nullSafety(Off)を使用して無効にすることができます。 Strictモードでは、nullの安全性が無効になっているコンテキストでも、nullを割り当てる可能性のあるフィールドミューテーションの関数呼び出しを調べます。

Ruby開発者は、便利な安全なナビゲーション演算子（Rubyでは?. ）がレーダーに乗っているかどうか疑問に思うかもしれません。 まだですが、Haxeのプログラミングの多くの側面と同様に、そのためのマクロがあります（代わりに!.を使用することに注意してください）。

Haxe 4の開発者エクスペリエンス（DX）：構文の追加、構文の砂糖など

Haxeプログラミング言語とHaxeIDEサポートへのDX関連の追加により、Haxe 4のエクスペリエンスは、さまざまな面で他のプログラミング言語と少なくとも同じレベルになります。 いくつかの点で、Haxeはすべての人にとってすべてになることを目指していますが、コンパイラチームは、他の言語の最も便利な機能と規則を統合するために思慮深いアプローチを取ります。

その結果、Haxeプログラミング言語と標準APIは、安定性、感度、まとまりを損なうことなく進化します。 このHaxeレビューのすべてが誇大広告に値するように見えるわけではありません。まさにそれがポイントです。DXは改善されており、これは単に派手な「featuresdujour」を追いかけることに賛成です。

ただし、バランスを取る必要があります。Haxeの変更は、他の言語が従うパターンを認識して行われ、Haxe 4は、より人気のある言語からの新規参入者にアピールするように努めています。

新しい「関数型」構文

その点で、Haxeは関数型を表す2つの主要な方法をサポートするようになりました。 元の機能提案によると、古い構文は「自動カリー化と部分適用がサポートされていることを示唆していますが、サポートされていません」。

 Int -> String -> Void

新しい構文では、名前付き引数が許可され、DXが改善されます。

 (id:Int, name:String) -> Void

ただし、DXは別として、関数型にHaxe 4の新しい構文を使用することは、古い、劣った構文が将来のメジャーバージョンで削除される可能性があるため、習得するのに適した習慣です。

シンタックスシュガー…

おそらくそれは画期的なことではありませんが、Haxe 4の構文の改善は、特定の開発バックグラウンド（ES6など）を持つ既存のHaxe開発者と、彼らから初めてHaxeに来る可能性のある開発者の両方にとって歓迎すべきニュースです。

矢印関数（「ショートラムダ」）構文がサポートされるようになりました。これは、Haxeの場合、多かれ少なかれ、 functionを入力して戻り値をreturnための単なるショートカットです。 キー値とインデックス値の反復構文（それぞれマップと配列）もサポートされるようになりました。 静的拡張を使用する型宣言は、対応する静的拡張メソッドが使用されるすべての場所で必要になるのではなく、グローバルに1つのusingステートメントを使用できます。

列挙型と列挙型の要約には他にもいくつかの改善点があります。そのうちの1つは、後者がマクロの範囲から直接コンパイラーのサポートに移行したことです。 同様に移動された他の機能には、finalクラス、finalインターフェース、およびexternフィールドが含まれます。

マクロに依存する一部の機能は、マクロに依存したままでしたが、それでも改善されました。 演算子のオーバーロードがレベルアップされ、フィールドセッターが含まれるようになり、メタデータに。で名前空間を付けることができるようになりました. @:prefix.subprefix.nameのような区切り文字。

上記の変更をシンタックスシュガーと呼ぶのは明らかに過度に単純化されていますが、読者は、Haxe4のリリースノートからリンクされている元の提案を掘り下げて詳細を確認することを歓迎します。

その他のHaxe4DXブースト

Haxeでは、コンパイルされたさまざまなターゲットに対してインタラクティブなデバッグがすでに可能でしたが、新しいevalターゲットにより、解釈されたコードに対してインタラクティブなデバッグが可能になります。 簡単な例として、Haxeの「Hello、World」チュートリアルのプロジェクトディレクトリを取得し、次のようなwhatever-you-want.hxmlというファイルを追加できます。

 --main HelloWorld --interp

…そして、VSCodeIDEでインタラクティブなデバッグを簡単に行うことができます。

  1. VSCodeでプロジェクトディレクトリを開きます。
  2. どこかにブレークポイントを追加します。 と
  3. F5キーを押して、ドロップダウンから「HaxeInterpreter」を選択します。

この機能を使用すると、（ --interpを使用するのではなく）実際にjavaなどの特定のターゲット用にコンパイルしている場合でも、同じ方法でマクロコードをインタラクティブにデバッグできます。 HaxeとVSCode自体以外の唯一のインストール要件は、HaxeVSCode拡張機能です。

IDEサービス

IDEと言えば、Haxe 4は新しいIDEサービスプロトコルを導入します。これは、最新のVSCodeHaxe拡張機能であるvshaxeですでに活用されています。 これにより、パフォーマンスが大幅に向上するだけでなく、vshaxeは次のような非常に便利なDXの改善を提供できます。

  • （待望の）自動インポート
  • オートコンプリートのホバーヒントは、「このフィールドはどこから来たのか」という質問に答えるなど、詳細を表示します。
  • 期待される型の補完、接尾辞の補完、オーバーライドの補完など、いくつかの洗練された新しい方法での非常に徹底的なオートコンプリート
  • コード入力中のキーストロークの最適化

関連するvshaxe変更ログからの優れたビジュアルデモを介して、これらの価値を確認する方がはるかに簡単です。 vshaxeを備えたvshaxeだけがHaxeIDEではありません。HaxeDevelopとKodeStudioはHaxe固有であり、IntelliJ IDEA、Sublime Text、AtomなどのHaxeIDEプラグインがあります。 Haxe 4の新しいIDEサービスプロトコルを利用し、続いてIntelliJ-Haxeを利用します。

Unicodeリテラル

実際のUnicode文字列リテラルを使用したい開発者はHaxe4でそれをサポートしますが、注意すべき微妙な違いがいくつかあります。

読み取り専用配列

標準のHaxeAPIに読み取り専用配列が追加されました。 これらは、変数をhaxe.ds.ReadOnlyArray<Int>のタイプであると宣言するのと同じくらい簡単に使用できます。その後、値を設定、プッシュ、またはポップしようとすると、さまざまなコンパイラエラーが発生します。 宣言にfinalキーワードを追加すると、配列自体の再割り当ても許可されなくなります。

呼び出しサイトのインライン化

呼び出しサイトのインライン化は、開発者が関数をインライン化する場所をきめ細かく制御できる新しいHaxe言語機能であり、全体的なサイズとパフォーマンスのトレードオフが負けの決定になる可能性がある頻繁に呼び出される関数を最適化する場合に役立ちます。

これらは、すでに優れたHaxeプログラミング言語に追加する価値があります。 Haxe 4がリリースされた今、Haxeコミュニティ構築の開発者は何ですか？

Haxeゲームエンジンを超えて：Haxe4を使用したWeb開発

Haxeのユーザーベースは、歴史的にゲームプログラマーによって支配されてきました。 しかし、フロントエンドとバックエンドの両方の開発のために、ビジネススタック、モバイルアプリ、Webなどの他のセグメントでHaxeが大規模に使用されている例はたくさんあります。

そのために、Haxe 4は再生成されたHTMLexternを提供します。つまり、Haxeのjs.html標準APIは、MDNが定義するより幅広いWeb APIで最新になり、バグを修正し、不足しているAPIを追加します。 （たとえば、Haxe4にはPushAPIが含まれるようになりました。）

Juraj Kirchheimの講演、Weaving a Better Web with Haxeで、彼は、HaxeベースのWebソリューションが、企業環境で桁違いに効率的でありながら、より堅牢である例を指摘しています。

彼はまた、Railsのアーキテクチャーアプローチ（フォルダー階層の観点から）にも反対していますが、Railsの完全なWebフレームワークを好む開発者はそれでも見つけることができます。 また、開発者が完全なWebプロジェクトのソースを確認することも有益な場合があります。その場合は、Haxe 4をサポートするクラウドギフトプラットフォームであるGiffonの公開リポジトリを確認する価値があります。同様に、Web中心のオープンなJavaScript分割HaxeModular、汎用thx.coreとその姉妹ライブラリ、由緒あるHaxe WebツールキットTinkerbellなどのソースHaxeライブラリはすべて、すでにHaxe 4をサポートしています。クロスプラットフォームUIソリューションHaxeUIもサポートしていますが、Webコンテキストをサポートしています。ビジネスおよびデスクトップアプリの開発を含む、はるかに広い範囲を対象としています。 特に、新しいHaxe言語のリリースに至るまで、着実に成熟し続けています。

Web、ゲーム、エンタープライズ…プラットフォームとアプリのフレーバーに関係なく、開発チームは、たとえ1つのチームであっても、最終的には依存関係の管理に取り組む必要があります。 このために、Haxe開発者がレビューするのに役立つリソースは、AdamBreeceの講演「他の人とうまくスケーリングする」のスライドです。

ゲームに最適なプログラミング言語としてのHaxe

ゲーム開発のための単一の「最良の」言語さえ存在しますか？ これは主観的な質問であり、白熱した議論を見つけるのは簡単です。 コミュニティの規模だけで予想されるよりも大きいので、ゲーム開発分野でのHaxeの成功は確かに偶然ではありません。 Joe Williamsonは、2019年にLudum Dare 45ゲームジャムに勝つことについてのインタビューでこれがなぜあるのかについての洞察を提供します。これは、Haxe4でも続く可能性があります。

Haxeの最初の作成者であるNicolasCannasseは、すでにShiroGamesのNorthgardでHaxe4を制作に使​​用しています。 Motion Twinは、DeadCellsの制作にもHaxe4を使用しています。 どちらのゲームもSteamで何万もの肯定的なレビューがあり、PC（Win、Mac、Linux）とコンソールの両方で利用できます。どちらのゲームも開発チームが小さく、ユーザーベースが数百万であることを考えると、本当に手ごわい結果です。 Dead Cellsには​​iOSバージョンもあり、Androidバージョンもレーダーに搭載されています。

ライブラリに関しては、いくつかの主要なHaxeゲームエンジンがHaxe4の変更に確実に対応しています。 Haxe 4互換エンジンには、Kha（およびその上に構築された多くのエンジンの一部（Armoryなど））、HaxeFlixelとその主な依存関係であるOpenFL、NME、およびヒープが含まれます。 HaxePunkはHaxe4の互換性にも取り組んでいます。 あるケースでは、ライブラリNapeがHaxe4で動作するようにフォークされました。

一部の開発者は、すでに存在する多くのエンジンの1つを使用する代わりに、独自のエンジンを作成することもあります。 たとえば、Kirill Poletaevは、彼が独自の3DHaxeゲームエンジンを作成した方法と理由を詳しく説明しています。 上記のエンジンは社内にあるため、Haxe4にまだ移行されていないプロジェクトの一例であることは理にかなっています。

Haxe 4：優れたツールチェーンのスムーズな進行を継続

Haxeは非常に幅広い有用性を備えているため、最も重要なHaxe 4の機能は開発者によって異なるため、このHaxeレビューは決して網羅的なものではありません。 Haxe 4の変更のいくつかは、上記にありません。

  • JavaScriptターゲットのES6出力の追加
  • 機能（一部はhx3compatライブラリから引き続き利用可能）とターゲット（PHP5およびまもなくAS3）の削除
  • CLIフラグが一般的なツールとの整合性を高めています（たとえば、 -lib -using .hxmlファイルは-Lまたは--libraryに変更する必要があります）。
  • finalがキーワード（したがって変数名として使用できない）であることに加えて、 operatorとoverloadも新しく予約されたキーワードです。

いくつかの重大な変更もありましたが、それらは非常に少ないため、アクティブに保守されているライブラリの多くは、Haxe 4の互換性を明示的に発表することすらしていません。一般に、Haxe3からの移行はかなり簡単であると言われています。 結局のところ、Haxeの目標の1つは、多数のターゲットプラットフォームのサポートを調整している最中の安定性であり、Haxe4はここで失望しません。

新規ユーザーはどうですか？ 結局、Haxeがゲームに最適なコーディング言語であるかどうか、HaxeエコシステムがWeb開発用の最も堅牢なライブラリを提供するかどうか、またはHaxe固有のツールが特定のワークフローに最も賢明なDXを提供するかどうかを判断するのは読者次第です。 少なくとも、Haxeは多くの分野で実行可能な競争相手であり続けており、ほぼすべての開発者に秘密の利点を提供しています。

さらに読む：Haxeを初めて使用する開発者は、John Gabrieleによるかなり新しいHaxeチュートリアル、およびHaxe4.1.0とHaxe4.1.1のリリースノートに興味があるかもしれません。