IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Bill Fassinou

347PARTAGES

12  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de nhugodot
Membre habitué https://www.developpez.com
Le 25/06/2020 à 0:07
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...
1  0 
Avatar de fy code
Membre du Club https://www.developpez.com
Le 15/06/2020 à 17:49
É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.
0  0 
Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 30/10/2020 à 19:55
... C'est plutôt Facebook qui devrait pousser a passer React sous ReasonML pour tous...
@nhugodot
+1, Enfin maintenant ils sont passer à ReScript (nouvelle syntaxe dédier à JS & empaquette/renommage de Bucklescript, mais ne permet plus la compilation en natif via OCaml).

Par contre, je regrette, mais Flutter est très loin de faire dans le "natif" puisque le Framework ce découpe en 3 couches :
  • le Framework Applicatif en Dart,
  • le moteur en C/C++ (contient également les plugins et autres)
  • et enfin l'Embedder à re-coder en natif pour chaque plateforme.


On est d'accord, c'est plus rapide que de dev sur une WebView à la Electron, NW.js ou autre truc à base de Chromium ou WebKit et ça ne demande pas d'empaqueter un serveur pour accéder aux ressources bas niveau, mais toujours est-il que le cross-plateforme et le natif ne ce rencontre pas si souvent.
0  0 
Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 16/06/2020 à 23:19
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.
0  1