Haxe Review: Haxe 4 คุณสมบัติและจุดแข็ง

การตรวจสอบ Haxe ก่อนหน้าของเราจบลงด้วยการดูที่ Haxe 4 ที่กำลังจะมีขึ้นในขณะนั้นด้วยการเปิดตัว Haxe 4 อย่างเป็นทางการ (และหลังจากนั้นไม่นาน การเปิดตัวแพตช์ข้อบกพร่องสองรายการ — เวอร์ชัน 4.0.1 และ 4.0.2) ก็ถึงเวลาสำหรับการตรวจสอบ Haxe ใหม่ . อะไรคือสิ่งที่เพิ่มเติมล่าสุดสำหรับภาษาการเขียนโปรแกรมที่กำลังเติบโตนี้? ชุมชนภาษาโปรแกรม Haxe มุ่งไปทางไหน? เอ็นจิ้นเกม Haxe ยังคงเป็นแกนนำหรือไม่?

Haxe Review: คุณสมบัติใหม่ของ Haxe 4

ด้วยการพัฒนามากกว่าสามปีนับตั้งแต่การเปิดตัวครั้งใหญ่ครั้งล่าสุด เวอร์ชัน 4 ของภาษาการเขียนโปรแกรม Haxe ปรับปรุงประสิทธิภาพของมาโคร ประสบการณ์ของนักพัฒนา และไวยากรณ์ การปรับปรุงสามอย่างยังคงถือว่าเป็นการทดลองแต่คุ้มค่าที่จะเน้น: เป้าหมายไบต์โค้ด JVM ใหม่ รองรับมาร์กอัปแบบอินไลน์ และการตรวจสอบความปลอดภัยที่เป็นโมฆะ

เป้าหมายการรวบรวม JVM Bytecode แบบทดลองใน Haxe 4

เป้าหมาย JVM bytecode ใหม่ของ Haxe 4 ทำให้การพัฒนา Java ผ่าน Haxe ค่อนข้างมีประสิทธิภาพมากขึ้นโดยการตัดขั้นตอนการคอมไพล์ที่สำคัญ: ไม่มีขั้นตอนที่สองในการมีคอมไพเลอร์ของ Java ( javac ) คอมไพล์เอาต์พุตซอร์สโค้ด Java ของ transpiler ของ Haxe

วิธีการคอมไพล์ด้วย Haxe 4 นี้จะลบการพึ่งพา Java Developer Kit (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 โดยเฉพาะ
• ประสิทธิภาพรันไทม์ ไม่ค่อย ดีนัก แม้ว่าในที่สุดแล้วจะเร็วกว่าวิธีทางอ้อมก็ตาม

อย่างไรก็ตาม เป็นขั้นตอนที่โดดเด่นในทิศทางที่ถูกต้องสำหรับทุกคนที่ใช้เทคโนโลยีที่ใช้จาวา

การสนับสนุนมาร์กอัปอินไลน์แบบทดลองใน Haxe 4

JSX ใคร? Haxe 4 เปิดใช้งานมาร์กอัปแบบอินไลน์ ช่วยให้นักพัฒนาสามารถเขียน HTML ได้โดยตรงภายในซอร์สโค้ด Haxe:

 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 ที่เฉพาะเจาะจงเป็นคำถามต่อไปสำหรับทีมคอมไพเลอร์และชุมชนที่จะต้องค้นหา

การทดสอบ Null Safety ใน Haxe 4

นับตั้งแต่การประดิษฐ์การอ้างอิง null ในปีพ. ศ. 2508 ปัญหาด้านความปลอดภัยที่เป็นโมฆะมักเป็นความหายนะของนักพัฒนาในสภาพแวดล้อมที่พิมพ์เป็นโมฆะได้เช่นเดียวกับภาษาโปรแกรม Haxe Aleksandr Kuzmenko ประมาณการว่า GitHub ดำเนินการแก้ไขข้อผิดพลาดในการอ้างอิงตัวชี้ null มากกว่า 10 ล้าน

Haxe 4 มีมาโครความปลอดภัย null เวลาคอมไพล์ในตัว ซึ่งสามารถเปิดใช้งานได้โดยการใส่บรรทัด @:nullSafety ก่อนคำจำกัดความที่กำหนด มันมาใน @:nullSafety(Loose) (ค่าเริ่มต้น) และ @:nullSafety(Strict) และสามารถปิดใช้งานได้ตามต้องการด้วย @:nullSafety(Off) โหมด Strict จะตรวจสอบการเรียกใช้ฟังก์ชันสำหรับการกลายพันธุ์ของฟิลด์ที่อาจกำหนด null แม้ในบริบทที่ปิดใช้งานความปลอดภัยเป็นค่าว่าง

นักพัฒนา Ruby อาจสงสัยว่าตัวดำเนินการการนำทางที่ปลอดภัยซึ่งสะดวก ( ?. ใน Ruby) อยู่ในเรดาร์หรือไม่ ยังไม่ใช่ แต่เช่นเดียวกับหลายๆ แง่มุมของการเขียนโปรแกรมใน Haxe มีมาโครสำหรับสิ่งนั้น (โปรดทราบว่ามันใช้ !. แทน)

Developer Experience (DX) กับ Haxe 4: Syntax Additions, Syntactic Sugar และอื่นๆ

การเพิ่มที่เกี่ยวข้องกับ DX ให้กับภาษาการเขียนโปรแกรม Haxe และการสนับสนุน Haxe IDE ทำให้ประสบการณ์ Haxe 4 อยู่ในระดับอย่างน้อยกับภาษาการเขียนโปรแกรมอื่น ๆ ในด้านต่างๆ ในบางวิธี Haxe พยายามที่จะเป็นทุกอย่างสำหรับทุกคน แต่ทีมคอมไพเลอร์ใช้แนวทางที่รอบคอบในการผสานรวมคุณลักษณะและรูปแบบที่เป็นประโยชน์ที่สุดจากภาษาอื่น

ผลลัพธ์คือภาษาการเขียนโปรแกรม Haxe และ API มาตรฐานมีวิวัฒนาการโดยไม่กระทบต่อความเสถียร ความอ่อนไหว และความเหนียวแน่น ไม่ใช่ทุกสิ่งในรีวิว Haxe นี้จะดูน่าดึงดูดใจ และนั่นคือประเด็นที่ถูกต้อง: DX กำลังพัฒนา และนี่คือการชอบไล่ตาม "คุณลักษณะ du jour " ที่ฉูดฉาด

มีความสมดุลที่จะเกิดขึ้น: การเปลี่ยนแปลงของ Haxe เสร็จสิ้นโดยตระหนักถึงรูปแบบที่ภาษาอื่นกำลังติดตาม และ Haxe 4 พยายามดึงดูดผู้ที่มาใหม่จากภาษาที่ได้รับความนิยมมากขึ้นอย่างแน่นอน

ใหม่ “ประเภทฟังก์ชัน” ไวยากรณ์

ในบันทึกย่อนั้น Haxe รองรับสองวิธีหลักในการแสดงประเภทฟังก์ชัน ไวยากรณ์เก่า “แนะนำว่ารองรับการเรียกอัตโนมัติและบางส่วน แต่ไม่รองรับ” ตามข้อเสนอคุณลักษณะดั้งเดิม:

 Int -> String -> Void

ไวยากรณ์ใหม่อนุญาตให้ใช้อาร์กิวเมนต์ที่มีชื่อ ซึ่งปรับปรุง DX:

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

แต่นอกเหนือจาก DX แล้ว การใช้ไวยากรณ์ใหม่ของ Haxe 4 สำหรับประเภทฟังก์ชันถือเป็นนิสัยที่ดี เนื่องจากไวยากรณ์เก่าที่ด้อยกว่าอาจถูกลบในเวอร์ชันหลักในอนาคต

น้ำตาลวากยสัมพันธ์…ประเภท

บางทีอาจจะไม่แหวกแนว แต่การปรับปรุงไวยากรณ์ของ Haxe 4 จะเป็นข่าวที่น่ายินดีสำหรับทั้งนักพัฒนา Haxe ที่มีอยู่ซึ่งมีภูมิหลังการพัฒนาบางอย่าง (เช่น ES6) และผู้ที่อาจมาจาก Haxe เป็นครั้งแรก

ฟังก์ชันลูกศร ("แลมบ์ดาสั้น") ได้รับการสนับสนุนแล้ว ซึ่งในกรณีของ Haxe เป็นเพียงทางลัดสำหรับการพิมพ์ function และ return ไม่มากก็น้อย ไวยากรณ์การวนซ้ำของคีย์-ค่าและดัชนี-ค่า (สำหรับแผนที่และอาร์เรย์ตามลำดับ) ได้รับการสนับสนุนด้วยเช่นกัน การประกาศประเภทโดยใช้ส่วนขยายแบบคงที่สามารถใช้เพียงคำสั่งเดียว using คำสั่งทั่วโลกแทนที่จะต้องใช้วิธีการขยายแบบคงที่ที่สอดคล้องกันทุกที่

Enums และ enum abstracts มีการปรับปรุงอื่นๆ ซึ่งหนึ่งในนั้นคือส่วนหลังได้เปลี่ยนจากขอบเขตของมาโครไปเป็นการรองรับคอมไพเลอร์โดยตรง คุณลักษณะอื่น ๆ ที่ย้ายไปในทำนองเดียวกัน ได้แก่ คลาสสุดท้าย อินเทอร์เฟซสุดท้าย และฟิลด์ภายนอก

คุณลักษณะบางอย่างที่อาศัยมาโครยังคงพึ่งพามาโคร แต่ก็ยังได้รับการปรับปรุงให้ดีขึ้น โอเวอร์โหลดโอเปอเรเตอร์ถูกปรับระดับขึ้นเพื่อรวมตัวตั้งค่าฟิลด์ และข้อมูลเมตาสามารถเนมสเปซด้วย . ตัวคั่นใน @: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 ใหม่ ซึ่งได้ใช้ประโยชน์แล้วใน vshaxe ส่วนขยาย VSCode Haxe ล่าสุด นอกจากการเพิ่มประสิทธิภาพที่สำคัญแล้ว ยังช่วยให้ vshaxe สามารถให้การปรับปรุง DX ที่มีประโยชน์อย่างยิ่ง ซึ่งรวมถึง:

• (รอมานาน) นำเข้าอัตโนมัติ
• คำแนะนำในการเติมข้อความอัตโนมัติที่แสดงรายละเอียดเพิ่มเติม เช่น การตอบคำถาม "ช่องนี้มาจากไหน"
• การเติมข้อความอัตโนมัติอย่างละเอียดถี่ถ้วนด้วยวิธีใหม่ๆ ที่ลื่นไหล เช่น ประเภทที่คาดว่าจะเสร็จสิ้น การแก้ไขภายหลังการแก้ไข และการแทนที่เสร็จสิ้น
• เพิ่มประสิทธิภาพการกดแป้นพิมพ์ลงในขณะที่พิมพ์โค้ด

ง่ายกว่ามากที่จะเห็นคุณค่าของสิ่งเหล่านี้ผ่านการสาธิตภาพที่ยอดเยี่ยมจาก vshaxe changelog ที่เกี่ยวข้อง vshaxe ที่มี VSCode ไม่ใช่ Haxe IDE ตัวเดียวที่อยู่รอบๆ — HaxeDevelop และ Kode Studio เป็นแบบเฉพาะของ Haxe และมีปลั๊กอิน Haxe IDE สำหรับ IntelliJ IDEA, Sublime Text, Atom และอื่นๆ—แต่ดูเหมือนว่าจะนำหน้าแพ็คในแง่ของ ของการใช้โปรโตคอลบริการ IDE ใหม่ของ Haxe 4 ตามด้วย IntelliJ-Haxe อย่างใกล้ชิด

Unicode Literals

นักพัฒนาที่ต้องการใช้ตัวอักษรสตริง Unicode จริงจะพบการสนับสนุนใน Haxe 4 แต่มีความแตกต่างบางประการที่ต้องระวัง

อาร์เรย์แบบอ่านอย่างเดียว

Haxe API มาตรฐานตอนนี้มีอาร์เรย์แบบอ่านอย่างเดียว สิ่งเหล่านี้ใช้งานง่ายพอๆ กับการประกาศตัวแปรให้เป็นประเภท เช่น haxe.ds.ReadOnlyArray<Int> หลังจากนั้นการพยายามตั้งค่า พุช หรือป๊อปค่าจะส่งผลให้เกิดข้อผิดพลาดของคอมไพเลอร์ต่างๆ เพิ่มคีย์เวิร์ด final ลงในการประกาศ และการกำหนดอาร์เรย์ใหม่เองจะไม่ได้รับอนุญาตเช่นกัน

Inlining ไซต์การโทร

การแทรกอินไลน์ของไซต์การโทรเป็นคุณลักษณะภาษา Haxe ใหม่ที่ช่วยให้นักพัฒนาสามารถควบคุมตำแหน่งที่ฝังฟังก์ชันได้อย่างละเอียด ซึ่งมีประโยชน์เมื่อปรับฟังก์ชันที่เรียกบ่อยให้เหมาะสมที่สุด ซึ่งการประนีประนอมกับขนาดโดยรวมอาจเป็นการตัดสินใจที่สูญเสียไป

สิ่งเหล่านี้เป็นส่วนเสริมที่คุ้มค่าสำหรับภาษาการเขียนโปรแกรม Haxe ที่ยอดเยี่ยมอยู่แล้ว นักพัฒนาซอฟต์แวร์ในชุมชน Haxe กำลังสร้างอะไรในตอนนี้ที่ Haxe 4 ออกมาแล้ว

Beyond Haxe Game Engines: การพัฒนาเว็บด้วย Haxe 4

ฐานผู้ใช้ของ Haxe ถูกครอบงำโดยโปรแกรมเมอร์เกมในอดีต แต่มีตัวอย่างมากมายของการใช้ Haxe—ในปริมาณมาก—ในกลุ่มอื่นๆ เช่น กองธุรกิจ แอพมือถือ และเว็บ ทั้งสำหรับการพัฒนาส่วนหน้าและส่วนหลัง

ด้วยเหตุนี้ Haxe 4 จึงจัดหา HTML externs ที่สร้างขึ้นใหม่ ซึ่งหมายความว่า API มาตรฐาน js.html ของ Haxe ได้รับการอัปเดตด้วย API เว็บที่กว้างขึ้นตามที่ MDN กำหนดไว้ เช่นเดียวกับการแก้ไขข้อผิดพลาดและเพิ่ม API ที่ขาดหายไป (เช่น ตอนนี้ Haxe 4 รวม Push API)

ในการพูดคุยของ Juraj Kirchheim เรื่อง Weaving a Better Web with Haxe เขาชี้ให้เห็นถึงตัวอย่างของโซลูชันเว็บที่ใช้ Haxe ที่มีลำดับความสำคัญมีประสิทธิภาพมากกว่า—แต่แข็งแกร่งกว่า—ในการตั้งค่าองค์กร

เขายังโต้แย้งกับแนวทางสถาปัตยกรรม Rails (ในแง่ของลำดับชั้นของโฟลเดอร์) แต่นักพัฒนาที่ชื่นชอบกรอบงานเว็บที่สมบูรณ์ซึ่ง la Rails ยังคงสามารถหาได้ ในบางครั้ง อาจเป็นประโยชน์กับนักพัฒนาในการทบทวนแหล่งที่มาของโครงการเว็บที่สมบูรณ์ ซึ่งในกรณีนี้ ควรพิจารณาซื้อคืนสาธารณะสำหรับ Giffon ซึ่งเป็นแพลตฟอร์มที่มอบของขวัญจากฝูงชนซึ่งสนับสนุน Haxe 4 ในทำนองเดียวกัน เว็บเป็นศูนย์กลาง เปิด- ไลบรารี Haxe ต้นทางเช่น Haxe Modular ที่แยก JavaScript, thx.core ทั่วไปและไลบรารีน้องสาวของมัน และชุดเครื่องมือเว็บ Haxe ที่เคารพนับถือ Tinkerbell ทั้งหมดสนับสนุน Haxe 4 อยู่แล้ว โซลูชัน UI ข้ามแพลตฟอร์ม HaxeUI ซึ่งสนับสนุนบริบทเว็บ แต่ กำหนดเป้าหมายขอบเขตที่กว้างกว่ามากรวมถึงการพัฒนาธุรกิจและแอพเดสก์ท็อป โดยเฉพาะอย่างยิ่งมันยังคงเติบโตอย่างต่อเนื่องซึ่งนำไปสู่การเปิดตัวภาษา Haxe ใหม่

เว็บ เกม องค์กร...โดยไม่คำนึงถึงแพลตฟอร์มและแอปที่พัฒนาทีมพัฒนา—แม้แต่ทีมเดียว—กำลังกำหนดเป้าหมาย นักพัฒนา Haxe จะต้องต่อสู้กับการจัดการการพึ่งพาในที่สุด สำหรับสิ่งนี้ แหล่งข้อมูลที่เป็นประโยชน์สำหรับนักพัฒนา Haxe ในการทบทวนคือสไลด์จากคำปราศรัยของ Adam Breece การปรับขนาดได้ดีกับคนอื่นๆ

Haxe เป็นภาษาการเขียนโปรแกรมที่ดีที่สุดสำหรับเกม

มีภาษาเดียวที่ "ดีที่สุด" สำหรับการพัฒนาเกมหรือไม่? เป็นคำถามเชิงอัตนัยและเป็นคำถามง่ายที่จะหาข้อโต้แย้งที่ร้อนแรง ใหญ่กว่าที่คาดไว้จากขนาดของชุมชนเพียงอย่างเดียว ความสำเร็จของ Haxe ในด้านการพัฒนาเกมไม่ใช่เรื่องบังเอิญอย่างแน่นอน Joe Williamson ให้ข้อมูลเชิงลึกว่าทำไมนี่อาจเป็นการสัมภาษณ์เกี่ยวกับการชนะเกม Ludum Dare 45 ในปี 2019 และดูเหมือนว่าจะดำเนินต่อไปใน Haxe 4

Nicolas Cannasse ผู้สร้างดั้งเดิมของ Haxe ใช้ Haxe 4 ในการผลิตร่วมกับ Northgard ของ Shiro Games Motion Twin ยังใช้ Haxe 4 ในการผลิต Dead Cells เกมทั้งสองมีบทวิจารณ์เชิงบวกนับหมื่นบน Steam และพร้อมใช้งานสำหรับทั้งพีซี (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: ดำเนินต่ออย่างราบรื่นของ Toolchain ที่ยอดเยี่ยม

เนื่องจาก Haxe มียูทิลิตี้ที่กว้างขวางเช่นนี้ ฟีเจอร์ที่สำคัญที่สุดของ Haxe 4 จะแตกต่างกันไปตามแต่ละผู้พัฒนา ดังนั้นการตรวจสอบ Haxe นี้ไม่ได้ครอบคลุมถึงรายละเอียดทั้งหมด การเปลี่ยนแปลงบางอย่างของ Haxe 4 หายไปข้างต้น รวมถึง:

• การเพิ่มเอาต์พุต ES6 สำหรับเป้าหมาย JavaScript
• การนำคุณลักษณะออก (บางส่วนยังคงมีอยู่ในไลบรารี hx3compat ) และเป้าหมาย (PHP5 และ AS3)
• แฟล็ก CLI ถูกทำให้สอดคล้องกับเครื่องมือทั่วไปมากขึ้น ( -lib .hxml ไฟล์จะต้องเปลี่ยนเป็น -L หรือ --library เป็นต้น)
• นอกจากจะใช้เป็นคีย์เวิร์ด final แล้ว (ซึ่งไม่สามารถใช้เป็นชื่อตัวแปรได้) operator และ overload ยังเป็นคีย์เวิร์ดที่สงวนไว้ใหม่อีกด้วย

นอกจากนี้ยังมีการเปลี่ยนแปลงที่แตกหัก แต่มีเพียงไม่กี่แห่งที่ไลบรารีที่ได้รับการดูแลอย่างแข็งขันจำนวนมากไม่สนใจที่จะประกาศความเข้ากันได้ของ Haxe 4 อย่างชัดเจน—โดยทั่วไป การโยกย้ายจาก Haxe 3 นั้นค่อนข้างตรงไปตรงมา ท้ายที่สุด หนึ่งในเป้าหมายของ Haxe คือความมั่นคงท่ามกลางการสนับสนุนการเล่นกลสำหรับแพลตฟอร์มเป้าหมายจำนวนมาก และ Haxe 4 ไม่ทำให้ผิดหวังที่นี่

แล้วผู้ใช้ใหม่ล่ะ? ในท้ายที่สุด มันขึ้นอยู่กับผู้อ่านที่จะตัดสินใจว่า Haxe เป็นภาษาเขียนโค้ดที่ดีที่สุดสำหรับเกมหรือไม่ ระบบนิเวศของ Haxe มีไลบรารี่ที่แข็งแกร่งที่สุดสำหรับการพัฒนาเว็บหรือไม่ หรือว่าเครื่องมือเฉพาะของ Haxe จะให้ DX ที่สมเหตุสมผลที่สุดสำหรับเวิร์กโฟลว์เฉพาะหรือไม่ อย่างน้อยที่สุด Haxe ยังคงเป็นคู่แข่งที่มีศักยภาพในหลายพื้นที่ โดยนำเสนอข้อได้เปรียบที่เป็นความลับสำหรับนักพัฒนาซอฟต์แวร์แทบทุกคน

อ่านเพิ่มเติม: นักพัฒนาที่เพิ่งเริ่มใช้ Haxe อาจสนใจบทช่วยสอน Haxe ที่ค่อนข้างใหม่โดย John Gabriele และบันทึกประจำรุ่นของ Haxe 4.1.0 และ Haxe 4.1.1