Discussion:Typage statique

Beaucoup d'articles importants pointent vers cet article dans leur phase de définition.

Il y a pourtant une erreur de titre (du type : deux <h2> précédés d'un <h3>) et surtout un emploi d'une terminologie informaticienne inexpliquée, sans oublier l'incompréhensible utilisation du mot nœud, tantôt avec O-E, tantôt avec Œ. J'ai peur de modifier sans savoir, et je laisse donc ici à plus expérimenté le soin de modifier et/ou répondre à ce message.

NucleoS 5 jul 2004 à 20:04 (CEST)

Pour l'erreur de titre, tu peux y aller :) Le noeud nŒud vient de ce que qqu'un a remplacé les uns par les autres, et j'ai remis des noeuds dans les fragments de code ; je suis navré, mais, au moins chez moi, le o dans le e est illisible à l'écran. Pour ce qui est de la terminologie informaticienne inexpliquée, si tu veux bien indiquer laquelle, je me ferai un plaisir, de donner les explications OU de fournir les liens nécessaires. Aurélien

Homer242 14 fev. 2006 à 17:27 (GMT+1)

Il n'y a pas une erreur dans la section "problème" à ce niveau là :

boolean ajout_noeud (Lien l) { ... } //modélisation covariante conforme à l'intuition

je verais plutot :

boolean ajout_noeud (Routeur r) { ... } //modélisation covariante conforme à l'intuition

j'ai juste ou j'ai vraiment rien compris ?

juste :) Aurélien 12 mars 2006 à 22:12 (CET) (PS : inscris-toi, ça évitera la prolifération des IP)

du typage statique et du typage en général

Salut je viens de lire l'article sur le typage statique, et je ne suis pas convaincu par les explications, en particulier les points suivants :

1. "modélisation « naturelle » du problème à résoudre", la modelisation proposé dans l'exemple ne semble pas la pertinente, il conviendrai d'utiliser des interface au lieu de la derivation, qui n'a que peux d'interet dans cette exemple.
2. l'exemple de code Java n'est pas conforme aux regles de nommage Java (ajout_noeud au lieu de ajoutNoeud) enfin l'utilisation du type que l'on passe en paramètre dans le nom de la méthode, est plutot mal choisi et ne peut conduire à des incompréhensions de la part de ceux qui ne connaissent pas Java.
3. La partie intitulée "Problème" ne prrésente pas un problème mais plutot une fonctionnalité.
4. la phrase : "Soient des classes A et B telles que B < A (« B spécialise A ») et B <: A (« B est un sous-type de A »); une méthode m(A) de type fonctionnel u→t définie sur A. Si B redéfinit m, alors le type de m(B) est u'→t' tels que u' <: u et t <: t', ce qui implique que u' < u et t < t'." n'explique pas la nature du problème/fonctionnalité.
5. La partie "Résolution, autres difficultés" utilise encore la derivation en lieu et place d'une utilisation des interfaces/programmation par contrat d'ou une explication non pertinente.
6. Il faudrait décrire les Classes Animal (ou mieu son interface) et Vache pour pouvoir dire que le type est correcte ou non.
7. La phrase : "Donc à l'exécution, la vache peut recevoir des farines animales. La maladie de la vache folle est une erreur de type, garantie par la sûreté du typage..." n'a pas d'interet surtout que le raisonnement qui y mene n'est pas correct.

Malheureusement devant autant d'inexactitudes, je suis déprimé et n'ai pas le courage d'essayer d'améliorer la page.

Ce que tu dis est étrange le sujet même de ces paragraphes est le sous-typage par héritage... Enfin de toute manière l'ensemble de l'article est a revoirOuts 24 juillet 2006 à 23:29 (CEST)

À recycler

J'ai apposé le bandeau à recycler :

• la majeur partie de l'article parle uniquement de problème du typage de l'héritage (covariance/contravariance)
• une fois enlevé cette partie il ne reste quasiement plus rien sur le sujet. A compléter donc
• Je me souviens qu'il y a des bouts parlant de typage dans d'autre article en particulier dans Programmation orientée objet qui aurait plus leurs places ici. Voir aussi, dans une moindre mesure, Variable ou Généricité
• Faire un tout cohérent avec Type, Sûreté du typage, Typage fort, Conversion de type, Théorie des types et Typage dynamique. Une fois tout rangé, il y aura surement des articles en trop

Outs 24 juillet 2006 à 23:50 (CEST)

Mise en perspective

• Fortran II (1957) avait pour règle : toute variable commençant par I,J,K,L,M,N est un entier ; toute autre est un réel. Cette règle a longtemps subsisté "par défaut", et est passée de Fortran à PL/1.
• Basic(1964) distinguait a (numérique) de a$ (chaine)...
• Dans les grammaires de van Wijngaarden, utilisables comme langage de programmation, truc123 est l'occurence 123 de la métanotion truc...

--Lf69100 (d) 24 mai 2013 à 12:27 (CEST)