FAQ DartConsultez toutes les FAQ

[Traduction de la FAQ officielle]

L'inférence de type n'est pas explicitement spécifiée dans la spécification du langage, mais elle est libre d'être implémentée ou pas. Il est important de se rappeler que Dart dispose d'un typage dynamique, de ce fait l'inférence de type ne joue pas du tout le même rôle que dans un langage comme Haskell par exemple. Cela dit, Dart Editor fait appel au mécanisme d'inférence de type quand vous utilisez des variables locales.

[Traduction de la FAQ officielle]

Nous voulons conserver le sentiment d'un langage typé dynamiquement familier aux développeurs Web. Imposer le typage n'est pas notre objectif. L'expérience montre que les langages à typage statique fort sont parfois trop rigides et nous voulons que Dart reste flexible pour une grande majorité de développeurs.

[Traduction de la FAQ officielle]

Plutôt que d'utiliser un système complet de typage statique, Dart possède un typage dynamique avec un typage statique optionnel via les annotations. Notre but est de supporter à travers ce typage divers outils ainsi que la documentation. Nous voulions disposer d'un outil léger d'aide à la programmation sans contraintes pour le développeur. En particulier, nous voulions des alertes statiques optimistes plutôt qu'un système qui se plaint d'un code typé dynamiquement qui peut s'avérer valide et correctement écrit, comme lors d'un transtypage parent. Parce que l'exécution de Dart ne peut avoir d'erreur liée au typage, on peut du coup omettre certains cas problématiques et les capturer à l'exécution à la place.

Les langages orientés objet vous permettent le transtypage parent qui amène aussi une incertitude dans le système de typage et qui peut résulter en une erreur de type à l'exécution. Avec Dart, on a opté pour la possibilité du transtypage parent sans identification syntaxique particulière.

[Traduction de la FAQ officielle]

La sûreté du typage peut aider en matière de performances, mais n'est pas essentielle. Nous privilégions l'uniformité et la simplicité sémantique. Les machines virtuelles modernes peuvent tout à fait utiliser le contrôle à l'exécution comme procédé d'optimisation.

[Traduction de la FAQ officielle]

Si les annotations avaient un effet à l'exécution, les programmes changeraient leur comportement dès l'ajout d'une annotation de type et ceci tant bien que la logique sous-jacente resterait inchangée. Le cours normal de développement est d'ajouter graduellement les types pour la documentation et la validation et si cela modifie ce que le programme fait, c'est que l'équipe n'a pas de fondations stables sur lesquelles continuer. Cela est particulièrement vrai étant donné que les types peuvent être inexacts.

En outre, cette politique nous permet ainsi qu'à d'autres d'ajouter des outils tiers de vérifications de types qui implémentent différentes règles sans interactions imprévues avec le code à l'exécution.

[Traduction de la FAQ officielle]

La covariance des génériques correspond à une intuition que les programmeurs ont et qui s'avère très souvent juste comme dans le « en lecture seule » d'un générique. Bien qu'elle ne soit pas toujours correcte, Dart n'en a pas besoin pour fonctionner. Dart a déjà opté pour une vérification statique optimiste, alors pourquoi ne pas continuer dans ce sens et autoriser l'usage de la covariance des génériques pour passer la validation statique ?

Malgré une covariance des génériques trop optimiste, l'exécution sans erreur de types de Dart permet que les alertes statiques soient optimistes sans être dangereuses. Bien que la covariance puisse être aussi pessimiste, nous pensons que c'est une situation rare et qu'il existe une solution simple pour tout pessimisme.

Nous sommes familiers avec les différents moyens des langages qui essaient de détecter ou de bloquer les problèmes de variance. Nous pensons qu'aucun n'est profitable à Dart et voulons que les annotations de types soient optionnelles et non intrusives : de toute façon, elles n'auraient pas pu être marquées et nous pensons que les systèmes gérant la variance ajoutent trop de complexité comparés à leur bénéfice.

Nous essayons d'être pragmatiques et pensons que les choix actuels sont raisonnables.

Les développeurs Java auraient le réflexe de faire ceci :

1
2
3
  
double myDouble = 2.2; 
int myInt = (int)myDouble;

1
2
3
  
double myDouble = 2.2; 
int myInt = (myDouble as int); // Erreur

1
2
3
4
5
6
  
int returnMe() 
{ 
    double myDouble = 2.2; 
    return myDouble.round(); 
}

print(returnMe().runtimeType); // => int

Le type num est simplement une classe abstraite qui sera convertie soit en int si la valeur est entière, soit en double si la valeur est flottante :

1
2
3
4
5
6
7
8
  
void main() 
{ 
  num myDouble = 2.2; 
  num myInt = 2; 
  print(myDouble.runtimeType); 
  print(myInt.runtimeType); 
}

1
2
3
  
double 
int