Haxe 評論：Haxe 4 功能和優勢

已發表: 2022-03-11

我們之前的 Haxe 評測以當時即將推出的 Haxe 4 結束。隨著 Haxe 4 的正式發布（以及此後不久的兩個錯誤補丁版本 - 版本 4.0.1 和 4.0.2），是時候進行新的 Haxe 評測了. 這種新興的編程語言的最新添加是什麼？ Haxe 編程語言社區將走向何方？ Haxe 遊戲引擎仍然是它的支柱嗎？

Haxe 評測：Haxe 4 的新功能

自上一個主要版本以來，經過三年多的開發，Haxe 編程語言版本 4 改進了宏性能、開發人員體驗和語法。 它的三個增強功能仍被認為是實驗性的，但值得強調：新的 JVM 字節碼目標、對內聯標記的支持和空安全檢查。

Haxe 4 中的實驗性 JVM 字節碼編譯目標

Haxe 4 的新 JVM 字節碼目標通過減少主要編譯步驟使通過 Haxe 進行 Java 開發更加高效：沒有第二步讓 Java 自己的編譯器 ( javac ) 編譯 Haxe 轉譯器的 Java 源代碼輸出。

為 Java 目標開發時，新的直接 JVM 目標與原始工作流的比較。原始文件需要一些 .hx 源，生成 .java 源，而在最終生成可運行的 .jar 文件之前，需要使用 Java 編譯器（取決於 JDK）對其進行編譯。新目標允許開發人員直接從 .hx 源轉到可運行的 .jar 文件。

這種使用 Haxe 4 編譯的方法也完全消除了對 Java 開發工具包 (JDK) 的依賴，為將來實現交互式調試打開了大門。

在hxjava的主流版本兼容 Haxe 4 之前，基本設置包括安裝 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 編譯在 Haxe 4 中仍處於實驗狀態，因此需要注意以下幾點：

  • 有一些特定於 Android 的問題。
  • 運行時性能不是很好，即使它最終會比間接方法更快。

儘管如此，對於任何利用基於 Java 的技術的人來說，這都是朝著正確方向邁出的顯著一步。

Haxe 4 中的實驗性內聯標記支持

JSX，有人嗎？ Haxe 4 支持內聯標記，允許開發人員直接在 Haxe 源代碼中編寫 HTML：

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

由於此處的jsx()可以是靜態宏函數，這允許項目在編譯時檢查標記是否符合開發人員希望實現的任何 XML-ish 規範。 由於 XML 支持本身內置在 Haxe API 中，因此檢查可以利用Xml.parse() ，但對於基本的“XML-ish”可解析性，甚至不需要：

 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 是編譯器團隊和社區要解決的下一個問題。

Haxe 4 中的實驗零安全性

自 1965 年空引用發明以來，空安全問題一直是開發人員在可空類型環境（如 Haxe 編程語言）中的禍根。 Aleksandr Kuzmenko 估計 GitHub 承諾修復的空指針引用錯誤數量超過 1000 萬。

Haxe 4 具有內置的編譯時空安全宏，可以通過在給定定義之前包含@:nullSafety行來啟用它。 它有@:nullSafety(Loose) （默認）和@:nullSafety(Strict)模式，可以根據需要使用@:nullSafety(Off) 。 Strict模式將通過函數調用查看可能分配 null 的字段突變，即使在 null 安全禁用上下文中也是如此。

Ruby 開發人員可能想知道方便的安全導航操作符（Ruby 中的?. ）是否受到關注。 還沒有，但與 Haxe 編程的許多方面一樣，有一個宏（請注意，它使用!.代替。）

Haxe 4 的開發人員體驗 (DX)：語法添加、語法糖等

Haxe 編程語言和 Haxe IDE 支持中與 DX 相關的附加功能使 Haxe 4 的體驗至少在各個方面與其他編程語言相當。 在某些方面，Haxe 力求成為所有人的一切，但編譯器團隊採取了一種深思熟慮的方法來集成來自其他語言的最有用的特性和約定。

結果是 Haxe 編程語言和標準 API 在不損害其穩定性、敏感性和凝聚力的情況下不斷發展。 並非本次 Haxe 評論中的所有內容都值得大肆宣傳，而這正是重點：DX 正在改進，這有利於簡單地追逐浮華的“日常功能”。

不過，有一個平衡點：Haxe 的變化是在意識到其他語言遵循的模式的情況下完成的，而 Haxe 4 肯定會努力吸引來自更流行語言的新手。

新的“函數類型”語法

關於這一點，Haxe 現在支持兩種主要的表示函數類型的方式。 根據原始功能提案，舊語法“建議支持自動柯里化和部分應用程序，但實際上不支持”：

 Int -> String -> Void

新語法允許命名參數，這改進了 DX：

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

但拋開 DX 不談，使用 Haxe 4 的新函數類型語法是一個很好的習慣，因為舊的、劣質的語法可能會在未來的主要版本中被刪除。

語法糖……有點

也許這不是開創性的，但是對於具有特定開發背景（例如 ES6）的現有 Haxe 開發人員以及可能第一次從他們那裡轉向 Haxe 的人來說，Haxe 4 的語法改進將是一個受歡迎的消息。

現在支持箭頭函數（“short lambda”）語法，在 Haxe 的情況下，這或多或少只是鍵入function和return的快捷方式。 現在也支持鍵值和索引值迭代語法（分別用於映射和數組）。 使用靜態擴展的類型聲明可以只使用一個全局using語句，而不是在使用相應靜態擴展方法的任何地方都需要它們。

枚舉和枚舉摘要還有其他一些改進，其中之一是後者已經從宏的範圍轉移到具有直接編譯器支持。 其他類似移動的特性包括最終類、最終接口和外部字段。

一些依賴宏的功能仍然依賴於宏，但仍然得到了改進。 運算符重載已升級為包含字段設置器，元數據現在可以使用. @:prefix.subprefix.name中的分隔符。

誠然，將上述更改稱為語法糖過於簡單，但歡迎讀者深入了解與 Haxe 4 發行說明相關的原始提案，他們需要更多細節。

更多 Haxe 4 DX 提升

雖然在 Haxe 中已經可以對各種編譯目標進行交互式調試，但新的eval目標使解釋代碼的交互式調試成為可能。 舉個簡單的例子，你可以在任何 Haxe “Hello, World” 教程的項目目錄中，添加一個名為whatever-you-want.hxml的文件，如下所示：

 --main HelloWorld --interp

…並通過以下方式在 VSCode IDE 中進行交互式調試：

  1. 在 VSCode 中打開項目目錄；
  2. 在某處添加斷點； 和
  3. 點擊 F5 並從下拉列表中選擇“Haxe Interpreter”。

此功能還允許您以相同的方式交互式地調試宏代碼，即使您實際上是針對java之類的特定目標進行編譯（而不是使用--interp ）。 除了 Haxe 和 VSCode 本身之外，唯一的安裝要求是 Haxe VSCode 擴展。

IDE 服務

說到 IDE，Haxe 4 引入了一個新的 IDE 服務協議，該協議已經在最新的 VSCode Haxe 擴展 vshaxe 中得到利用。 除了顯著的性能提升之外，這還允許 vshaxe 提供一些非常有用的 DX 改進，包括：

  • （期待已久）自動導入
  • 顯示更多詳細信息的自動完成懸停提示，例如回答問題“該字段來自哪裡？”
  • 以幾種巧妙的新方式非常徹底的自動完成，如預期類型完成、後綴完成和覆蓋完成
  • 輸入代碼時的按鍵優化

通過相關 vshaxe 更改日誌中的出色視覺演示，可以更容易地看到這些的價值。 帶有vshaxe的 vshaxe 並不是唯一的 Haxe IDE——HaxeDevelop 和 Kode Studio 是 Haxe 特有的，還有適用於 IntelliJ IDEA、Sublime Text、Atom 等的 Haxe IDE 插件——但它似乎在這些方面領先利用 Haxe 4 的新 IDE 服務協議，緊隨其後的是 IntelliJ-Haxe。

Unicode 文字

想要使用真正的 Unicode 字符串文字的開發人員會在 Haxe 4 中找到對它的支持，但需要注意一些細微差別。

只讀數組

標準 Haxe API 現在具有隻讀數組。 這些與將變量聲明為類型一樣易於使用，例如haxe.ds.ReadOnlyArray<Int> ，之後嘗試設置、推送或彈出值會導致各種編譯器錯誤。 將final關鍵字添加到聲明中，並且重新分配數組本身也將被禁止。

調用點內聯

調用點內聯是一項新的 Haxe 語言功能，允許開發人員對函數內聯的位置進行細粒度控制，這在優化經常調用的函數時很有用，否則整體大小-性能權衡可能是一個雙輸的決定。

這些是對已經非常出色的 Haxe 編程語言的有價值的補充。 Haxe 4 發布後，Haxe 社區建設中的開發人員有哪些？

超越 Haxe 遊戲引擎：使用 Haxe 4 進行 Web 開發

Haxe 的用戶群歷來由遊戲程序員主導。 但是，在其他領域（如業務堆棧、移動應用程序和 Web）中，有很多大規模使用 Haxe 的例子，用於前端和後端開發。

為此，Haxe 4 提供了重新生成的 HTML extern，這意味著 Haxe 的js.html標準 API 已與 MDN 定義的更廣泛的 Web API 保持同步，並修復了錯誤並添加了缺失的 API。 （例如，Haxe 4 現在包含 Push API。）

在 Juraj Kirchheim 的演講“用 Haxe 編織一個更好的 Web”中，他指出了基於 Haxe 的 Web 解決方案在企業環境中的效率要高出幾個數量級，同時也更加健壯的例子。

他還反對 Rails 架構方法（在文件夾層次結構方面），但喜歡完整的 Web 框架（如 Rails）的開發人員仍然可以找到一個。 其他時候，查看完整 Web 項目的源代碼可能會使開發人員受益，在這種情況下，值得查看 Giffon 的公共存儲庫，這是一個支持 Haxe 4 的眾籌平台。同樣，以 Web 為中心的開放式源 Haxe 庫，如 JavaScript 拆分 Haxe Modular、通用 thx.core 及其姊妹庫，以及古老的 Haxe web 工具包 Tinkerbell 都已經支持 Haxe 4。跨平台 UI 解決方案 HaxeUI 也是如此，它支持 web 上下文但針對更廣泛的範圍，包括業務和桌面應用程序開發； 尤其是在新的 Haxe 語言發布之前，它一直在穩步持續成熟。

Web、遊戲、企業……無論開發團隊（甚至是一個團隊）所針對的平台和應用程序風格如何，Haxe 開發人員最終都將不得不努力管理依賴關係。 為此，Haxe 開發人員查看的一個有用資源是 Adam Breece 演講中的幻燈片，即 Scaling well with others。

Haxe 是最好的遊戲編程語言

是否存在一種用於遊戲開發的單一“最佳”語言？ 這是一個主觀問題，很容易引起激烈的爭論。 Haxe 在遊戲開發領域的成功遠遠超出了人們對其社區規模的預期，這當然不是巧合。 喬·威廉姆森 (Joe Williamson) 在一次關於贏得 2019 年 Ludum Dare 45 比賽果醬的採訪中提供了一些見解，解釋了為什麼這可能會在 Haxe 4 中繼續下去。

Haxe 的原創者 Nicolas Cannasse 已經在 Shiro Games 的 Northgard 中使用 Haxe 4。 Motion Twin 還在《死亡細胞》的製作中使用 Haxe 4。 這兩款遊戲在 Steam 上都獲得了數以萬計的正面評價，並且可用於 PC（Win、Mac 和 Linux）和遊戲機——考慮到這兩款遊戲的開發團隊規模較小但用戶群數以百萬計，這確實是一個令人敬畏的結果。 Dead Cells 甚至有一個 iOS 版本，還有一個 Android 版本。

圖書館方面，幾個主要的 Haxe 遊戲引擎肯定與 Haxe 4 的變化保持同步。 與 Haxe 4 兼容的引擎自然包括 Kha（以及在它之上構建的許多引擎的一部分，例如 Armory）、HaxeFlixel 及其主要依賴項 OpenFL、NME 和 Heaps，因為這就是 Northgard 和 Dead Cells 使用的。 HaxePunk 也在致力於 Haxe 4 的兼容性； 在一個案例中，一個名為 Nape 的庫被分叉來與 Haxe 4 一起工作。

一些開發人員還製作自己的引擎，而不是使用現有的眾多引擎之一。 例如，Kirill Poletaev，他詳細介紹了他如何以及為何編寫自己的 3D Haxe 遊戲引擎。 由於所述引擎是內部的，因此它是一個尚未遷移到 Haxe 4 的項目示例是有道理的。

Haxe 4：繼續優秀工具鏈的平穩發展

由於 Haxe 具有如此廣泛的實用性，最重要的 Haxe 4 功能將因開發人員而異，因此此 Haxe 評論絕不是詳盡無遺的。 上面缺少 Haxe 4 的一些更改，包括：

  • 為 JavaScript 目標添加 ES6 輸出
  • 刪除功能（其中一些仍可通過hx3compat庫獲得）和目標（PHP5 和即將推出的 AS3）
  • CLI 標誌與常用工具更加一致（例如-lib .hxml文件需要更改為-L或--library ）。
  • 除了final now 是關鍵字（因此不能用作變量名）之外， operator和overload也是新保留的關鍵字。

也有一些重大更改，但它們太少了，以至於許多積極維護的庫甚至都懶得明確宣布 Haxe 4 的兼容性——總的來說，據說從 Haxe 3 遷移相當簡單。 畢竟，Haxe 的目標之一是在同時支持大量目標平台的過程中保持穩定，而 Haxe 4 在這方面並沒有讓人失望。

新用戶呢？ 最後，由讀者決定 Haxe 是否是最好的遊戲編碼語言，Haxe 生態系統是否為 Web 開發提供最強大的庫，或者 Haxe 特定工具是否為特定工作流程提供最明智的 DX。 至少，Haxe 在許多領域仍然是一個可行的競爭者，為幾乎所有開發人員提供了某種秘密優勢。

進一步閱讀：剛接觸 Haxe 的開發人員可能會對 John Gabriele 的相當新的 Haxe 教程以及 Haxe 4.1.0 和 Haxe 4.1.1 的發行說明感興趣。