Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    L’équipe de Dart annonce l’arrivée d’une « sécurité null » dans le langage de programmation
    L’équipe de Dart annonce l’arrivée d’une « sécurité null » dans le langage de programmation
    pour permettre aux développeurs de rendre leurs applications plus stables et plus performantes

    Les erreurs nulls sont très fréquentes, ce qui dérange beaucoup les développeurs. Pour résoudre ce problème dans le langage Dart, l’équipe de développement a annoncé l’arrivée de la fonctionnalité "sound null safety" ou "sécurité null sonore". La sécurité null vous permet d’éviter une classe de bogues souvent difficiles à repérer, et en prime, elle apporte aussi une gamme d’améliorations des performances. L’équipe Dart vient de publier un premier aperçu de cette fonctionnalité déclarant que la version stable arrive bientôt. En attendant, vous pouvez l'essayer.

    D’après l’équipe, Dart est un langage type-safe. En effet, cela signifie que lorsque vous avez une variable d'un certain type, le compilateur peut garantir qu'elle est de ce type. Mais la sécurité des types ne garantit pas à elle seule que la variable n'est pas “null”, ce qui joue des tours à beaucoup de développeurs. Selon l’équipe Dart, il n’y a qu’à faire une recherche sur GitHub pour obtenir des milliers de problèmes causés par des nulls dans le code Dart et des milliers de commits essayant de résoudre ces problèmes. C’est pour cela que l’équipe Dart introduit cette fonctionnalité.

    La fonctionnalité de sécurité null fait disparaître ce problème, selon l’équipe. Lorsque vous optez pour la sécurité null, les types de votre code sont non-nuls par défaut, ce qui veut dire que les valeurs ne peuvent être nulles que si vous décidez qu'elles peuvent l'être. Avec la sécurité null, vos erreurs liées à une référence null à l'exécution se transforment en erreurs d'analyse au moment de l'édition. Avec une sécurité null, l'analyseur Dart applique les bonnes pratiques. Par exemple, il s'assure que vous vérifiez la présence de zéros avant de lire une variable annulable.


    « Et parce que la sécurité null de Dart est solide, les compilateurs et les exécutions de Dart peuvent optimiser les vérifications null internes, de sorte que les applications peuvent être plus rapides et plus petites », lit-on dans la documentation de la fonctionnalité. Selon elle, quand Dart analyse votre code et détermine qu'une variable est non nulle, cette variable est toujours non nulle. Si vous inspectez votre code en cours d'exécution dans le débogueur, vous verrez que la non-nullabilité est conservée au moment de l'exécution. Ce qui diffère d’autres implémentations, selon l’équipe.

    Ces dernières doivent encore effectuer des vérifications concernant la non-nullabilité au moment de l’exécution. Toutefois, elle estime que Dart partage sa sécurité null sonore avec le langage Swift. Voici ci-dessous les principes sous lesquelles Dart a défini sa sécurité null :

    • non-nullable par défaut : à moins que vous n'indiquiez explicitement à Dart qu'une variable peut être nulle, elle sera considérée comme non nulle. L’équipe dit avoir choisi cette option par défaut, car elle a constaté que non-null était de loin le choix le plus courant dans les API ;
    • adoptable par étapes : il y a beaucoup de codes Dart. Il doit être possible de migrer progressivement vers la sécurité null, partie par partie. Il doit être possible d'avoir du code null-safe et non null-safe dans le même projet. L’équipe estime qu’il fournira des outils afin d’aider les développeurs dans cette migration ;
    • entièrement sûr : comme mentionné ci-dessus, la sécurité nulle de Dart est solide. Une fois que vous avez migré l'ensemble de votre projet et de vos dépendances vers la sécurité null, vous profitez pleinement des avantages de la solidité.

    En outre, la sécurité null de Dart est rétrocompatible. Cela signifie que le code existant peut faire appel à un code qui utilise la sécurité null, et vice versa. « Même lorsque la sécurité null sera disponible, ce sera une fonction optionnelle que vous pourrez adopter lorsque vous serez prêt. Votre code existant continuera à marcher sans changement », a déclaré l’équipe. Comme exemple de rétrocompatibilité de la sécurité null, elle a déclaré avoir remplacé les bibliothèques centrales existantes sans aucune rupture dans les tests existants et les applications de test fonctionnant dans les environnements de test Dart et Flutter.

    Sources : L’équipe Dart, Documentation de l’outil

    Et vous ?

    Avez-vous déjà rencontré une fois l'erreur null en Dart ?
    Que pensez-vous de la solution apportée par l'équipe de développement de Dart ?

    Voir aussi

    Le SDK de Dart 2.6 est disponible et s'accompagne de la possibilité de compiler des programmes Dart en exécutables autonomes grâce à dart2native

    Google : le SDK Dart 2.5 va « Supercharger » les développeurs, avec un aperçu de la complétion automatique du code alimentée par le Machine Learning. Flutter 1.9 est également disponible

    Flutter de Google : 2 millions de développeurs, hausse de l'utilisation par les entreprises et révélation d'un nouveau processus de mise à jour du framework
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre du Club
    Très bonne nouvelle !
    Étant un utilisateur régulier de flutter, cette nouvelle me fait plaisir.

    J'espère que la génération protobuf passera aussi toutes les variables en non nullable par défaut.
    Yann F. – Directeur Informatique
    Développement web et logiciel et sur mesure à Toulouse
    L'agence : Ewolis

    Très ouvert aux dialogues sur les développements, sciences et musicaux

    J'adore Golang et je suis fan de Jetbrain

  3. #3
    Membre extrêmement actif
    Honnêtement, pour un langage sortie en 2011, il contient beaucoup trop d'erreurs de jeunesse de Java, malheureusement.
    J'étais fan au débuts, quand il était encore présenté comme alternatives à JS, mais depuis que TypeScript, ReasonML, ELM et Co, sont sorties c'est vraiment dure de lui trouver des raisons d’exister.
    Flutter est vraiment une bonne idée, mais Dart est plus un frein qu'un moteur à sont adoption.
    Alors quand je lis l'article, je me dit juste "Chouette Dart est à la traine par rapport à Java", cherchez l’erreur .
    Non, vraiment sur ce coup là Google à vraiment fait du grand nawak et c'est bien dommage je trouve.

  4. #4
    Membre régulier
    Sans doute, mais Google a choisi de créer Flutter pour créer un framework non pas web , concurrent de React dont il s'inspire, mais pour Android et iOS , donc en natif, pas sur la VM JS... Et cherchait alors un langage compilable nativement sur ces deux OS mobiles. Ni TS ni ReasonML ou Elm ne le peuvent. On a au contraire de la chance d'avoir un Dart aussi polymorphe capable de se complier nativement sur tout OS (Swift, je te parle...) Mais aussi d'être transpilé en JS pour tourner néanmoins sur la VM web... Voire même d'avoir la VM Dart sous Chrome (pour les parcs d'entreprise par exemple ). Et de ne pas rebuter le parc immense de codeurs objet (java, serveurs web ou application Android surtout) plutôt que les perdre dans la programmation fonctionnelle.

    C'est plutôt Facebook qui devrait pousser a passer React sous ReasonML pour tous...