Examen de Haxe : caractéristiques et points forts de Haxe 4

Notre précédent examen de Haxe s'est terminé par un aperçu du Haxe 4 à venir. Avec la sortie officielle de Haxe 4 (et peu de temps après, deux versions de correctifs de bogues - versions 4.0.1 et 4.0.2), il est temps pour un nouvel examen de Haxe . Quels sont les derniers ajouts à ce langage de programmation en plein essor ? Où va la communauté du langage de programmation Haxe ? Les moteurs de jeu Haxe sont-ils toujours son pilier ?

Haxe Review : les nouvelles fonctionnalités de Haxe 4

Avec plus de trois ans de développement depuis la dernière version majeure, la version 4 du langage de programmation Haxe améliore les performances des macros, l'expérience des développeurs et la syntaxe. Trois de ses améliorations sont toujours considérées comme expérimentales mais méritent d'être soulignées : la nouvelle cible de bytecode JVM, la prise en charge du balisage en ligne et les contrôles de sécurité nuls.

La cible expérimentale de compilation de bytecode JVM dans Haxe 4

La nouvelle cible de bytecode JVM de Haxe 4 rend le développement Java via Haxe un peu plus efficace en supprimant une étape de compilation majeure : il n'y a pas de deuxième étape pour que le propre compilateur de Java ( javac ) compile la sortie du code source Java du transpileur de Haxe.

Cette méthode de compilation avec Haxe 4 supprime également entièrement la dépendance au kit de développement Java (JDK) et ouvre la porte à un débogage interactif à implémenter à l'avenir.

Jusqu'à ce que la version grand public de hxjava soit compatible avec Haxe 4, la configuration de base consiste à installer Haxe et Haxelib, puis à exécuter haxelib install hxjava 4.0.0-alpha . Cela fait, le flux de développement est simple :

 # 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

Étant donné que la compilation JVM directe a toujours un statut expérimental dans Haxe 4, elle s'accompagne de quelques mises en garde :

• Certains problèmes sont spécifiques à Android.
• Les performances d'exécution ne sont pas aussi bonnes, même si elles seront finalement plus rapides que la méthode indirecte.

Néanmoins, il s'agit d'un pas notable dans la bonne direction pour quiconque utilise les technologies basées sur Java.

Prise en charge expérimentale du balisage en ligne dans Haxe 4

JSX, quelqu'un? Haxe 4 permet le balisage en ligne, permettant aux développeurs d'écrire, par exemple, du HTML directement dans le code source Haxe :

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

Étant donné que jsx() ici peut être une fonction de macro statique, cela permet à un projet d'avoir des vérifications au moment de la compilation pour savoir si le balisage est conforme à la spécification XML que le développeur souhaite implémenter. Étant donné que la prise en charge XML elle-même est intégrée à l'API Haxe, la vérification peut tirer parti Xml.parse() , mais pour une analyse de base "XML-ish", même cela n'est pas nécessaire :

 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); } }

L'intention de cette fonctionnalité est d'aider à sortir Haxe de la bulle de développement de jeux (bien qu'il y ait sûrement des utilisations là aussi). Il est assez général qu'il soit implémenté au niveau du compilateur - donc pas besoin de l'API Haxe dans la macro ci-dessus - mais la vérification des DSL spécifiques est la prochaine question que l'équipe du compilateur et la communauté doivent résoudre.

Sécurité nulle expérimentale dans Haxe 4

Depuis l'invention de la référence null en 1965, la question de la sécurité null a souvent été le fléau des développeurs dans des environnements typés nullables comme celui du langage de programmation Haxe. Aleksandr Kuzmenko estime que GitHub s'engage à corriger un nombre d'erreurs de référence de pointeur nul supérieur à 10 millions.

Haxe 4 a des macros de sécurité nulles intégrées au moment de la compilation, qui peuvent être activées en incluant une ligne @:nullSafety juste avant une définition donnée. Il est disponible en @:nullSafety(Loose) (par défaut) et @:nullSafety(Strict) et peut être désactivé selon les besoins avec @:nullSafety(Off) . Le mode Strict recherchera dans les appels de fonction les mutations de champ susceptibles d'attribuer la valeur null, même dans un contexte de sécurité désactivée.

Les développeurs Ruby peuvent se demander si l'opérateur pratique de navigation sûre ( ?. en Ruby) est sur le radar. Pas encore, mais comme pour de nombreux aspects de la programmation dans Haxe, il existe une macro pour cela (notez qu'elle utilise !. à la place.)

Expérience de développeur (DX) avec Haxe 4 : ajouts de syntaxe, sucre syntaxique, etc.

Les ajouts liés à DX au langage de programmation Haxe et à la prise en charge de l'IDE Haxe apportent l'expérience Haxe 4 au moins au niveau d'autres langages de programmation sur divers fronts. À certains égards, Haxe cherche à être tout pour tout le monde, mais l'équipe du compilateur adopte une approche réfléchie pour intégrer les fonctionnalités et les conventions les plus utiles d'autres langages.

Le résultat est que le langage de programmation Haxe et l'API standard évoluent sans compromettre leur stabilité, leur sensibilité et leur cohésion. Tout dans cette revue Haxe ne semblera pas digne d'intérêt, et c'est précisément le but : DX s'améliore, et c'est en faveur de la simple chasse aux « fonctionnalités du jour ».

Il y a cependant un équilibre à trouver : les changements de Haxe sont effectués en tenant compte des modèles que les autres langues suivent, et Haxe 4 fait certainement un effort pour attirer les nouveaux arrivants de langues plus populaires.

Nouvelle syntaxe "Type de fonction"

Sur cette note, Haxe prend désormais en charge deux manières principales de représenter les types de fonctions. L'ancienne syntaxe "suggère que le curry automatique et l'application partielle sont pris en charge, mais ils ne le sont pas", selon la proposition de fonctionnalité d'origine :

 Int -> String -> Void

La nouvelle syntaxe autorise les arguments nommés, ce qui améliore DX :

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

Mais DX mis à part, utiliser la nouvelle syntaxe de Haxe 4 pour les types de fonctions est une bonne habitude à prendre, car l'ancienne syntaxe inférieure pourrait être supprimée dans une future version majeure.

Sucre syntaxique… en quelque sorte

Ce n'est peut-être pas révolutionnaire, mais les améliorations syntaxiques de Haxe 4 seront une bonne nouvelle à la fois pour les développeurs Haxe existants avec certains antécédents de développement (ES6, par exemple) et pour ceux qui pourraient en venir à Haxe pour la première fois.

La syntaxe de la fonction fléchée ("short lambda") est maintenant prise en charge, ce qui dans le cas de Haxe est plus ou moins simplement un raccourci pour taper function et return . Les syntaxes d'itération clé-valeur et index-valeur (pour les cartes et les tableaux, respectivement) sont désormais également prises en charge. Les déclarations de type utilisant des extensions statiques peuvent simplement utiliser une instruction using globalement au lieu d'en avoir besoin partout où les méthodes d'extension statiques correspondantes sont utilisées.

Les énumérations et les résumés d'énumération ont quelques autres améliorations, dont l'une est que ces dernières sont passées du domaine des macros à la prise en charge directe du compilateur. D'autres fonctionnalités déplacées de la même manière incluent les classes finales, les interfaces finales et les champs externes.

Certaines fonctionnalités reposant sur des macros sont restées dépendantes des macros, mais se sont néanmoins améliorées. La surcharge des opérateurs a été améliorée pour inclure les setters de champs, et les métadonnées peuvent désormais être placées dans un espace de noms avec . séparateurs comme dans @:prefix.subprefix.name .

Appeler les changements ci-dessus du sucre syntaxique est certes trop simpliste, mais les lecteurs sont invités à creuser dans les propositions originales liées aux notes de publication de Haxe 4 où ils ont besoin de plus de détails.

Plus de boosts Haxe 4 DX

Alors que le débogage interactif était déjà possible dans Haxe pour diverses cibles compilées, la nouvelle cible eval rend possible le débogage interactif pour le code interprété. Pour un exemple simple, vous pouvez prendre n'importe quel répertoire de projet du didacticiel Haxe "Hello, World", ajouter un fichier appelé whatever-you-want.hxml ressemblant à ceci :

 --main HelloWorld --interp

…et obtenez un débogage interactif dans l'IDE VSCode simplement en :

1. Ouverture du répertoire du projet dans VSCode ;
2. Ajouter un point d'arrêt quelque part ; et
3. Appuyez sur F5 et choisissez "Haxe Interpreter" dans le menu déroulant.

Cette fonctionnalité vous permet également de déboguer de manière interactive le code de macro de la même manière, même si vous compilez réellement pour une cible particulière comme java (plutôt que d'utiliser --interp ). La seule exigence d'installation en plus de Haxe et VSCode eux-mêmes est l'extension Haxe VSCode.

Services EDI

En parlant d'IDE, Haxe 4 introduit un nouveau protocole de services IDE, qui est déjà exploité dans la dernière extension VSCode Haxe, vshaxe. Outre une amélioration significative des performances, cela permet à vshaxe de fournir des améliorations DX extrêmement utiles, notamment :

• Importations automatiques (longtemps attendues)
• Des conseils de survol de saisie semi-automatique affichant plus de détails, comme répondre à la question "D'où vient ce champ ?"
• Auto-complétion très complète de plusieurs nouvelles manières astucieuses, comme l'achèvement de type attendu, l'achèvement de suffixe et l'achèvement de remplacement
• Optimisations jusqu'à la frappe lors de la saisie du code

Il est beaucoup plus facile de voir la valeur de ceux-ci via les excellentes démos visuelles du journal des modifications vshaxe pertinent. vshaxe avec VSCode n'est pas le seul IDE Haxe autour - HaxeDevelop et Kode Studio sont spécifiques à Haxe, et il existe des plugins Haxe IDE pour IntelliJ IDEA, Sublime Text, Atom, etc. - mais il semble être en avance sur le pack en termes d'utiliser le nouveau protocole de services IDE de Haxe 4, suivi de près par IntelliJ-Haxe.

Littéraux Unicode

Les développeurs souhaitant utiliser de vrais littéraux de chaîne Unicode trouveront un support pour cela dans Haxe 4, mais il y a quelques nuances à prendre en compte.

Tableaux en lecture seule

L'API Haxe standard dispose désormais de tableaux en lecture seule. Celles-ci sont aussi faciles à utiliser que de déclarer une variable comme étant du type, par exemple, haxe.ds.ReadOnlyArray<Int> , après quoi essayer de définir, de pousser ou d'extraire des valeurs entraîne diverses erreurs de compilation. Ajoutez le mot-clé final à la déclaration et la réaffectation du tableau lui-même sera également interdite.

Inlining du site d'appel

L'inlining du site d'appel est une nouvelle fonctionnalité du langage Haxe permettant aux développeurs de contrôler avec précision l'endroit où les fonctions sont intégrées, utile lors de l'optimisation des fonctions fréquemment appelées où le compromis global taille-performance pourrait autrement être une décision perdant-perdant.

Ce sont des ajouts intéressants au déjà excellent langage de programmation Haxe. Qu'est-ce que les développeurs de la communauté Haxe construisent maintenant que Haxe 4 est sorti ?

Au-delà des moteurs de jeu Haxe : développement Web avec Haxe 4

La base d'utilisateurs de Haxe a toujours été dominée par les programmeurs de jeux. Mais il existe de nombreux exemples d'utilisation de Haxe, à grande échelle, dans d'autres segments, tels que les piles d'entreprise, les applications mobiles et le Web, à la fois pour le développement front-end et back-end.

À cette fin, Haxe 4 fournit des externes HTML régénérés, ce qui signifie que l'API standard js.html de Haxe a été mise à jour avec l'API Web plus large telle que MDN la définit, ainsi que la correction des bogues et l'ajout d'API manquantes. (Par exemple, Haxe 4 inclut désormais l'API Push.)

Dans l'exposé de Juraj Kirchheim, Tisser un meilleur Web avec Haxe, il cite des exemples de solutions Web basées sur Haxe qui sont des ordres de grandeur plus efficaces, mais aussi plus robustes, dans un environnement d'entreprise.

Il s'oppose également à l'approche architecturale Rails (en termes de hiérarchie des dossiers), mais les développeurs qui privilégient un framework Web complet à la Rails peuvent toujours en trouver un. D'autres fois, il peut être avantageux pour les développeurs de revoir la source d'un projet Web complet, auquel cas il vaut la peine de jeter un coup d'œil au dépôt public de Giffon, une plate-forme de dons de foule qui prend en charge Haxe 4. De même, centré sur le Web, ouvert- Les bibliothèques source Haxe telles que Haxe Modular, le thx.core générique et ses bibliothèques sœurs, et la vénérable boîte à outils Web Haxe Tinkerbell prennent déjà en charge Haxe 4. Il en va de même pour la solution d'interface utilisateur multiplateforme HaxeUI, qui prend en charge un contexte Web mais cible une portée beaucoup plus large, y compris le développement d'applications professionnelles et de bureau ; en particulier, il a régulièrement continué à mûrir jusqu'à la nouvelle version du langage Haxe.

Web, jeux, entreprise… quelle que soit la plate-forme et la saveur de l'application qu'une équipe de développement, même une équipe d'un seul, cible, les développeurs de Haxe devront éventuellement s'attaquer à la gestion des dépendances. Pour cela, une ressource utile pour les développeurs Haxe à examiner est les diapositives de l'exposé d'Adam Breece, Bien évoluer avec les autres.

Haxe comme meilleur langage de programmation pour les jeux

Existe-t-il un seul "meilleur" langage pour le développement de jeux ? C'est une question subjective, et il est facile de trouver des débats passionnés. Plus grand que ce à quoi on pourrait s'attendre de la seule taille de sa communauté, le succès de Haxe dans le domaine du développement de jeux n'est certainement pas une coïncidence. Joe Williamson explique pourquoi cela pourrait être dans une interview sur la victoire du game jam Ludum Dare 45 en 2019, et cela semble susceptible de continuer avec Haxe 4.

Le créateur original de Haxe, Nicolas Cannasse, utilise déjà Haxe 4 en production avec Northgard de Shiro Games. Motion Twin utilise également Haxe 4 en production pour Dead Cells. Les deux jeux ont des dizaines de milliers de critiques positives sur Steam et sont disponibles pour les PC (Win, Mac et Linux) et les consoles - un résultat vraiment formidable étant donné que les deux jeux ont des équipes de développement plus petites mais des bases d'utilisateurs par millions. Dead Cells a même une version iOS, avec une version Android également sur leur radar.

En ce qui concerne la bibliothèque, plusieurs moteurs de jeu Haxe majeurs suivent définitivement les changements de Haxe 4. Les moteurs compatibles avec Haxe 4 incluent Kha (et une partie des nombreux moteurs construits dessus, par exemple Armory), HaxeFlixel et sa principale dépendance OpenFL, NME et Heaps, naturellement, puisque c'est ce que Northgard et Dead Cells utilisent. HaxePunk travaille également sur la compatibilité Haxe 4 ; dans un cas, une bibliothèque, Nape, a été bifurquée pour fonctionner avec Haxe 4.

Certains développeurs créent également leurs propres moteurs au lieu d'utiliser l'un des nombreux déjà disponibles. Par exemple, Kirill Poletaev, qui détaille comment et pourquoi il a écrit son propre moteur de jeu 3D Haxe. Étant donné que ledit moteur est interne, il est logique qu'il s'agisse d'un exemple de projet qui n'a pas encore migré vers Haxe 4.

Haxe 4 : Poursuivre la progression en douceur d'une excellente chaîne d'outils

Avec Haxe ayant une telle utilité, les fonctionnalités les plus importantes de Haxe 4 varient selon le développeur, donc cette revue Haxe n'est en aucun cas exhaustive. Certaines des modifications de Haxe 4 sont manquantes ci-dessus, notamment :

• L'ajout de la sortie ES6 pour la cible JavaScript
• La suppression des fonctionnalités (dont certaines sont encore disponibles via la librairie hx3compat ) et des cibles (PHP5 et bientôt AS3)
• Les indicateurs CLI sont rendus plus cohérents avec les outils courants (les fichiers -lib -using .hxml devront être remplacés par -L ou --library , par exemple).
• Outre que final est désormais un mot-clé (qui ne peut donc pas être utilisé comme nom de variable), operator et overload sont également des mots-clés nouvellement réservés.

Il y a également eu quelques changements de rupture, mais ils sont si peu nombreux que de nombreuses bibliothèques activement maintenues ne prennent même pas la peine d'annoncer explicitement la compatibilité Haxe 4 - en général, la migration depuis Haxe 3 est considérée comme assez simple. Après tout, l'un des objectifs de Haxe est la stabilité au milieu de la prise en charge jonglante d'un grand nombre de plates-formes cibles, et Haxe 4 ne déçoit pas ici.

Qu'en est-il des nouveaux utilisateurs ? En fin de compte, c'est au lecteur de décider si Haxe est le meilleur langage de codage pour les jeux, si l'écosystème Haxe offre les bibliothèques les plus robustes pour le développement Web, ou si les outils spécifiques à Haxe donnent le DX le plus sensible pour un flux de travail particulier. À tout le moins, Haxe continue d'être un concurrent viable dans de nombreux espaces, offrant un avantage secret à presque tous les développeurs.

Lectures complémentaires : les développeurs qui découvrent Haxe peuvent être intéressés par un didacticiel Haxe relativement récent de John Gabriele, ainsi que par les notes de publication de Haxe 4.1.0 et Haxe 4.1.1.