في 26 أكتوبر ، استضافت Linz am Rhein (ألمانيا) المؤتمر المصغر HaxeUp Sessions 2019 المخصص لـ Haxe والتقنيات ذات الصلة. وكان الحدث الأهم ، بالطبع ، هو الإصدار النهائي من Haxe 4.0.0 (في وقت النشر ، أي بعد حوالي أسبوع ، تم إصدار التحديث 4.0.1 ). في هذه المقالة ، أود أن أقدم لكم ترجمة للتقرير الأول للمؤتمر - تقرير عن العمل الذي أنجزه فريق Haxe لعام 2019.
قليلا عن مؤلف التقرير:
يعمل سايمون مع Haxe منذ عام 2010 ، عندما كان لا يزال طالبًا وكتب عملاً عن محاكاة السوائل في Flash. يتطلب تنفيذ مثل هذه المحاكاة وصولاً مستمراً إلى البيانات التي تصف حالة الجسيمات (في كل خطوة ، تم إجراء أكثر من 100 استفسار لصفائف البيانات حول حالة كل خلية في المحاكاة) ، في حين أن العمل مع المصفوفات في ActionScript 3 ليس بهذه السرعة. لذلك ، كان التنفيذ الأولي ببساطة غير فعال ويحتاج إلى إيجاد حل لهذه المشكلة. في بحثه ، صادف سايمون مقالًا لنيكولاس كاناس ( مؤلف Haxe ) عن رموز أكيمياء الخيميائية التي لم يتم توثيقها آنذاك والتي لم تكن متاحة باستخدام ActionScript ، لكن Haxe سمح لهم باستخدامها. إعادة كتابة المحاكاة على Haxe باستخدام رموز التشغيل ، حصل Simon على محاكاة عملية! وهكذا ، وبفضل الصفيفات البطيئة في ActionScript ، تعرف سيمون على Haxe.
منذ عام 2011 ، التحق سيمون بتطوير Haxe ، وبدأ في دراسة OCaml (وهو مكتوب على المحول البرمجي) وإجراء تصحيحات متنوعة على المحول البرمجي.
ومنذ عام 2012 ، أصبح مطور برامج التحويل البرمجي الرئيسي. في نفس العام ، تم إنشاء مؤسسة Haxe (وهي منظمة أهدافها الرئيسية هي تطوير وصيانة النظام البيئي Haxe ، ومساعدة المجتمع على تنظيم المؤتمرات والخدمات الاستشارية) ، وأصبح سيمون أحد مؤسسيها.
في 2014-2015 ، دعا سيمون جوزفين بيرتوسا إلى مؤسسة Haxe ، والتي أصبحت مع مرور الوقت مسؤولة عن تنظيم المؤتمرات والعلاقات المجتمعية.
في عام 2016 ، قدم سيمون عرضه التقديمي الأول حول Haxe ، وفي عام 2018 نظّم أول جلسات HaxeUp .
إذن ما الذي حدث في عالم Haxe خلال 2019 الماضية؟
في شباط (فبراير) وآذار (مارس) ، خرج اثنان من مرشحي الإصدار (4.0.0-rc1 و 4.0.0-rc2)
في أبريل ، انضم أوريل بيلي (كمتدرب) وألكسندر كوزمينكو (كمطور برامج ترجمة) إلى فريق Haxe Foundation.
في مايو ، عقدت قمة Haxe الأمريكية 2019 .
في يونيو ، تم إصدار Haxe 4.0.0-rc3. وفي سبتمبر - Haxe 4.0.0-rc4 و Haxe 4.0.0-rc5.
Haxe ليس فقط مترجمًا ، ولكنه أيضًا مجموعة كاملة من الأدوات المتنوعة ، كما تم إجراء العمل عليها باستمرار على مدار العام:
بفضل جهود آندي لي ، يستخدم Haxe الآن خطوط أنابيب Azure بدلاً من Travis CI و AppVeyor. هذا يعني أن التجميع والاختبارات الآلية أصبحت الآن أسرع بكثير.
يواصل هيو ساندرسون العمل على hxcpp (مكتبة لدعم C ++ في Haxe).
فجأة ، انضم مستخدمو Github terurou و takashiski إلى العمل على externs لـ Node.js.
عمل Rudy Ges على الإصلاحات والتحسينات لدعم الهدف C #.
يواصل جورج كورني دعم مولد HTML الخارجي.
يعمل Jens Fisher على vshaxe (امتداد لرمز VS للعمل مع Haxe) وفي العديد من المشاريع الأخرى المتعلقة بـ Haxe.
والحدث الرئيسي لهذا العام ، بالطبع ، كان الإصدار الذي طال انتظاره من Haxe 4.0.0 (وكذلك neko 2.3.0) ، والذي تزامن بطريق الخطأ مع HaxeUp 2019 Linz :)
كرس سيمون الجزء الأكبر من التقرير لميزات جديدة في Haxe 4.0.0 (يمكنك أيضًا التعرف عليها من تقرير ألكسندر كوزمينكو من آخر قمة Haxe US 2019).
مترجم الماكرو eval الجديد أسرع عدة مرات من القديم. تحدث سايمون عنه بالتفصيل في خطابه في Haxe Summit EU 2017 . ولكن منذ ذلك الحين قامت بتحسين إمكانيات تصحيح الأخطاء في الكود ، وإصلاح العديد من الأخطاء ، وإعادة تصميم تنفيذ السلاسل.
Haxe 4 يقدم دعم Unicode لجميع المنصات (باستثناء Neko). وصف سايمون هذا بالتفصيل في خطاب العام الماضي . بالنسبة للمستخدم النهائي للمترجم ، هذا يعني أن تعبير "Haxeは最高だぞ！".length جميع الأنظمة الأساسية سيعود دائمًا 10 (مرة أخرى ، باستثناء Neko).
يتم دعم تشفير UCS-2 إلى الحد الأدنى (يتم استخدام ترميز معتمد أصليًا لكل نظام أساسي / لغة ؛ ستكون محاولة دعم نفس الترميز في كل مكان أمرًا غير عملي):
- تستخدم JavaScript و Flash و HashLink و C ++ ترميز UCS-2
- ل eval ، PHP ، لوا - UTF-8
- لجافا و C # - UTF-16
- لبيثون - UTF-32
يتم تمثيل جميع الأحرف الموجودة خارج المستوى الرئيسي متعدد اللغات (بما في ذلك الرموز التعبيرية) كـ "أزواج بديلة" - يتم تمثيل هذه الأحرف بواسطة وحدتي بايت. على سبيل المثال ، إذا كان في Java / C # / JavaScript (أي ، السلاسل في تشفير UTF-16 و UCS-2) لطلب طول سلسلة تتكون من رمز تعبيري واحد ، ستكون النتيجة "2". يجب أن تؤخذ هذه الحقيقة في الاعتبار عند العمل مع هذه السلاسل على هذه المنصات.
يقدم Haxe 4 نوعًا جديدًا من التكرار - القيمة الأساسية:
إنه يعمل مع حاويات من النوع Map (قواميس) وسلاسل (باستخدام فئة StringTools) ، لم يتم تنفيذ دعم المصفوفات بعد. من الممكن أيضًا تطبيق هذا التكرار للفئات المخصصة ، ولهذا يكفي تنفيذ طريقة keyValueIterator():KeyValueIterator<K, V> لهم keyValueIterator():KeyValueIterator<K, V> .
العلامة الوصفية الجديدة @:using تتيح لك الاستخدام ربط الإضافات الثابتة بأنواع في مكان إعلانها.
في المثال الموضح في الشريحة أدناه ، يرتبط تعداد MyOption بـ MyOptionTools ، لذلك نقوم بتوسيع هذا التعداد بشكل ثابت (وهو أمر مستحيل في الموقف المعتاد) ونحصل على فرصة للاتصال بأسلوب get() ، مع الإشارة إليه كطريقة كائن.
في هذا المثال ، تكون طريقة get() مضمّنة ، مما يسمح أيضًا للمترجم بتحسين التعليمة البرمجية: بدلاً من استدعاء الأسلوب MyOptionTools.get(myOption) ، سيقوم المحول البرمجي باستبدال القيمة المخزنة ، أي 12 .
إذا لم يتم الإعلان عن الطريقة على أنها قابلة للتضمين ، فإن أداة التحسين الأخرى المتاحة للمبرمج هي تضمين الوظائف في مكان مكالمتهم (تضمين موقع الاتصال). للقيام بذلك ، عند استدعاء الوظيفة ، يجب عليك بالإضافة إلى ذلك استخدام inline :
بفضل عمل Daniil Korostelev ، أصبح لدى Haxe الآن الفرصة لإنشاء فصول ES6 لجافا سكريبت. كل ما عليك القيام به هو مجرد إضافة علامة -D js-es=6 .
حاليًا ، يقوم المترجم بإنشاء ملف js واحد للمشروع بأكمله (قد يكون من الممكن في المستقبل إنشاء ملفات js منفصلة لكل فئة من الفئات ، ولكن حتى الآن لا يمكن القيام بذلك إلا باستخدام أدوات إضافية ).
بالنسبة للتعدادات المجردة ، يتم الآن إنشاء القيم تلقائيًا.
في Haxe 3 ، كان من الضروري تعيين القيم يدويًا لكل مُنشئ. في Haxe 4 ، تتصرف التعدادات المجردة التي تم إنشاؤها أعلى Int وفقا للقواعد نفسها كما في C. تتعارض تعدادات الملخصات المُنشأة أعلى السلاسل - بالنسبة لهم ، تتزامن القيم التي تم إنشاؤها مع أسماء المُنشئات.
بعض التحسينات في بناء الجملة تستحق الذكر:
- أصبحت التعدادات المجردة والوظائف الخارجية أعضاء كاملين في Haxe ، والآن لا تحتاج إلى استخدام
@:enum و @:extern علامات التعريف الخارجية للإعلان عنها - يستخدم 4th Haxe بناء جملة تقاطع نوع جديد يعكس بشكل أفضل جوهر توسع الهياكل. تكون هذه الإنشاءات مفيدة للغاية عند التصريح بهياكل البيانات: التعبير
typedef T = A & B يعني أن الهيكل T يحتوي على جميع الحقول الموجودة في النوعين A و B - وبالمثل ، فإن أربعة معلمات لنوع معلنة النوع: يشير الإدخال
<T:A & B> إلى أن نوع المعلمة T يجب أن يكون A و B - سيعمل بناء الجملة القديم (باستثناء بناء الجملة لقيود النوع ، لأنه سيتعارض مع بناء الجملة الجديد لوصف أنواع الوظائف)
بناء الجملة الجديد لوصف أنواع الوظائف (بناء جملة نوع الوظيفة) أكثر منطقية: استخدام الأقواس حول أنواع وسيطات الوظيفة أسهل في القراءة. بالإضافة إلى ذلك ، يسمح لك بناء الجملة الجديد بتحديد أسماء الوسائط ، والتي يمكن استخدامها كجزء من وثائق التعليمات البرمجية (على الرغم من أنها لا تؤثر على الكتابة نفسها).
في هذه الحالة ، يستمر بناء الجملة القديم في الدعم ولا يتم إهماله ، كما خلاف ذلك ، سيتطلب الكثير من التغييرات في الكود الموجود (سيمون نفسه يجد نفسه دائمًا خارج العادة ويستمر في استخدام بناء الجملة القديم).
Haxe 4 يحتوي أخيرًا على وظائف السهم (أو تعبيرات lambda)!
ميزات وظائف السهم في Haxe هي:
return ضمنية. إذا كان نص الدالة يتكون من تعبير واحد ، فسوف تُرجع هذه الوظيفة ضمنياً قيمة هذا التعبير- من الممكن ضبط أنواع وسائط الدالة ، لأن لا يمكن للمترجم تحديد النوع المطلوب دائمًا (مثل
Float أو Int ) - إذا كان جسم الوظيفة يتكون من عدة تعبيرات ، فأنت بحاجة إلى تطويقها بأقواس مجعدة
- ولكن لا توجد طريقة لتعيين نوع الإرجاع للدالة بشكل صريح
بشكل عام ، يشبه بناء جملة وظائف السهم جدًّا تلك المستخدمة في Java 8 (على الرغم من أنها تعمل بشكل مختلف إلى حد ما).
وبما أننا ذكرنا Java ، فيجب أن يقال أنه في Haxe 4 أصبح من الممكن إنشاء JVM bytecode مباشرة. للقيام بذلك ، عند ترجمة مشروع تحت Java ، ما عليك سوى إضافة علامة -D jvm .
يعني إنشاء رمز JVM bytecode أنه لا توجد حاجة لاستخدام برنامج التحويل البرمجي لـ Java ، وأن عملية الترجمة أسرع بكثير.
حتى الآن ، فإن هدف JVM له حالة تجريبية للأسباب التالية:
- في بعض الحالات ، يكون كود البايت أبطأ قليلاً من نتيجة ترجمة Haxe في Java ثم التحويل البرمجي باستخدام javac. لكن فريق المترجم يدرك المشكلة ويعرف كيفية حلها ، إنه يتطلب فقط عملاً إضافياً.
- هناك مشاكل في MethodHandle على Android ، والتي تتطلب أيضًا عملًا إضافيًا (سيكون سايمون سعيدًا إذا ساعد في حل هذه المشكلات).
مقارنة عامة لتوليد bytecode مباشرة (genjvm) وتجميع Haxe في كود Java ، والذي يتم تجميعه بعد ذلك في bytecode (genjava):
- كما ذكرنا من قبل ، من حيث سرعة التجميع ، فإن جينجفم أسرع من جينجافا
من حيث سرعة التنفيذ ، لا يزال bytecode genjvm أدنى من genjava - هناك بعض المشاكل عند استخدام معلمات النوع و genjava
- يستخدم genJvm MethodHandle للإشارة إلى الوظائف ، ويستخدم genjava ما يسمى بـ "وظائف Waneck " (تكريماً لـ Kaui Vanek ، وبفضل دعم Java و C # ظهر في Haxe). على الرغم من أن الكود الذي تم الحصول عليه باستخدام وظائف Waneck لا يبدو جميلًا ، إلا أنه يعمل ويعمل بسرعة كافية.
نصائح عامة للعمل مع Java في Haxe:
- نظرًا لحقيقة أن أداة تجميع مجمعي البيانات المهملة في Java سريعة ، فإن المشكلات المرتبطة بها نادرة. بالطبع ، لا يعد إنشاء كائنات جديدة باستمرار فكرة جيدة ، ولكن Java تتكيف بشكل جيد مع إدارة الذاكرة والحاجة إلى الاعتناء بالتخصيصات باستمرار ليست حادة كما هي الحال في بعض الأنظمة الأساسية الأخرى التي يدعمها Haxe (على سبيل المثال ، في HashLink)
- يمكن الوصول إلى حقول فئة في هدف jvm ببطء شديد في الحالة عندما يتم ذلك من خلال بنية (
typedef ) - في حين أن المترجم لا يمكنه تحسين مثل هذا الرمز - يجب تجنب الاستخدام المفرط للكلمة الرئيسية
inline - يقوم برنامج التحويل البرمجي JIT بعمل جيد جدًا - تجنب استخدام
Null<T> ، خاصةً عند التعامل مع العمليات الحسابية المعقدة. وإلا ، ستظهر الكثير من العبارات الشرطية في الشفرة التي تم إنشاؤها ، مما سيؤثر سلبًا على سرعة الشفرة.
يمكن أن تساعد ميزة Haxe 4 الجديدة ، وهي Null safety ، في تجنب استخدام Null<T> . تحدث ألكساندر كوزمينكو بالتفصيل عنها في HaxeUp العام الماضي .
في المثال الموجود في الشريحة أعلاه ، يحتوي الأسلوب safe() الثابت على وضع Strict للتحقق من تمكين الأمان Null ، وهذه الطريقة لها معلمة arg اختيارية ، والتي يمكن أن تحتوي على قيمة فارغة. لكي تتم ترجمة هذه الوظيفة بنجاح ، سيحتاج المبرمج إلى إضافة التحقق من قيمة arg وسيطة (وإلا ، سيعرض المترجم رسالة حول استحالة استدعاء الأسلوب charAt() على كائن لاغٍ).
يمكن تكوين الأمان الفارغ على مستوى الحزمة (باستخدام ماكرو) وأنواع وحقول الكائنات الفردية (باستخدام العلامة الوصفية @:nullSafety ).
الأوضاع التي تعمل فيها Null Security هي: Strict و Loose و Off. على الصعيد العالمي ، يتم تعطيل هذه الاختبارات (خارج الوضع). عند تشغيلها ، يتم استخدام وضع فضفاض بشكل افتراضي (إلا إذا قمت بتحديد الوضع صراحة). يتمثل الاختلاف الرئيسي بين وضعي السائبة ووضعي Strict في أن وضع Loose يتجاهل إمكانية تغيير القيم بين عمليات الوصول إلى هذه القيم. في المثال الموجود في الشريحة أدناه ، نرى أنه قد تمت إضافة null للمتغير x . ومع ذلك ، في وضع صارم ، لا يتم ترجمة هذا الرمز ، لأن قبل العمل مباشرة مع المتغير x ، sideEffect() طريقة sideEffect() ، والتي يمكن أن تبطل قيمة هذا المتغير ، لذلك سوف تحتاج إلى إضافة فحص آخر أو نسخ قيمة المتغير إلى متغير محلي ، والتي سنواصل العمل معها.
يقدم Haxe 4 كلمة أساسية final جديدة لها معنى مختلف حسب السياق:
- إذا كنت تستخدمها بدلاً من الكلمة الأساسية
var ، فلن يمكن تعيين قيمة جديدة للحقل المعلن بهذه الطريقة. يمكنك فقط تعيينها مباشرة عند التصريح (للحقول الثابتة) أو في المُنشئ (للحقول غير الثابتة) - إذا كنت تستخدمه عند إعلان الفصل ، فستحظر الميراث منه
- إذا كنت تستخدمه كمعدل للوصول إلى خاصية كائن ما ، فإن هذا يحظر إعادة تعريف getter / setter في فصول الوريث.
من الناحية النظرية ، يمكن للمترجم ، بعد أن قابل الكلمة الرئيسية final ، أن يحاول تحسين الكود ، على افتراض أن قيمة هذا الحقل لا تتغير. لكن في الوقت الحالي ، يتم النظر في هذا الاحتمال فقط ولا يتم تنفيذه في المترجم.
والقليل حول مستقبل Haxe:
- تعمل حاليًا على واجهة I / O غير المتزامنة
يتم دعم دعم Coroutine ، ولكن حتى الآن ، تم تعليق العمل عليهما في مرحلة التخطيط. ربما سوف تظهر في Haxe 4.1 ، وربما في وقت لاحق. - سيظهر أمثل ذيل الدعوة في المترجم
- وربما الوظائف المتاحة على مستوى الوحدة . على الرغم من أن أولوية هذه الميزة تتغير باستمرار