Oui et tu fais quoi si la lib que tu utilises n'emploie pas les mêmes conventions de documentation que toi ou que le dev n'a pas documenté tous les aspects.
Heu... la convention de documentation par excellence, c'est le langage naturel (l'anglais de préférence). Si la lib que tu utilises est documentée en islandais ou pas documentée du tout, le mot-clé "protected" ne va pas t'apporter grand'chose.
Je préfère faire confiance à la machine plutôt que m'en remettre à l'humain et à son inconstance.
L'humain est inconstant mais il est capable de faire passer des idées qu'un langage formel ne permet en général pas (ou alors au prix d'une lourdeur énorme : tu peux toujours créer des "ontologies" et coder ta doc en RDF (et qui débugge la doc ? :-)).
Bref, il est délicat de savoir où situer la frontière entre les deux. La distinction typage statique / typage dynamique relève aussi en partie de cette frontière (en partie seulement, cf. ci-dessous).
Autant faire confiance au typage statique.
Mais le typage statique étant statique, ta fonction "sum" qui additionne des entiers est impropre à l'addition d'autres choses que des entiers (par exemple, des réels ou des complexes). Il n'est pas sans contrepartie.
Apparemment certains langages (Haskell ?) ont un typage structurel, c'est-à-dire une sorte de duck typing à la compilation, où la vérification des arguments consiste à tester qu'ils supportent les bonnes opérations (et non pas qu'ils sont instances d'un type donné). Qu'on me corrige si je me trompe, mais ça me semble une version plus intéressante du typage statique.
La boucle prototypage en langage dynamique et réécriture en langage statique a des fins d'optimisations ou de qualité est plus simple avec le couple Groovy/Java que le couple Python/C.
En pratique on ne réécrit jamais de code Python en C, sauf parfois quelques bouts très critiques.
[^] # Re: Excellente nouvelle
Posté par Antoine . En réponse à la dépêche Google Web Toolkit sous licence Apache 2.0. Évalué à 2.
Heu... la convention de documentation par excellence, c'est le langage naturel (l'anglais de préférence). Si la lib que tu utilises est documentée en islandais ou pas documentée du tout, le mot-clé "protected" ne va pas t'apporter grand'chose.
Je préfère faire confiance à la machine plutôt que m'en remettre à l'humain et à son inconstance.
L'humain est inconstant mais il est capable de faire passer des idées qu'un langage formel ne permet en général pas (ou alors au prix d'une lourdeur énorme : tu peux toujours créer des "ontologies" et coder ta doc en RDF (et qui débugge la doc ? :-)).
Bref, il est délicat de savoir où situer la frontière entre les deux. La distinction typage statique / typage dynamique relève aussi en partie de cette frontière (en partie seulement, cf. ci-dessous).
Autant faire confiance au typage statique.
Mais le typage statique étant statique, ta fonction "sum" qui additionne des entiers est impropre à l'addition d'autres choses que des entiers (par exemple, des réels ou des complexes). Il n'est pas sans contrepartie.
Apparemment certains langages (Haskell ?) ont un typage structurel, c'est-à-dire une sorte de duck typing à la compilation, où la vérification des arguments consiste à tester qu'ils supportent les bonnes opérations (et non pas qu'ils sont instances d'un type donné). Qu'on me corrige si je me trompe, mais ça me semble une version plus intéressante du typage statique.
La boucle prototypage en langage dynamique et réécriture en langage statique a des fins d'optimisations ou de qualité est plus simple avec le couple Groovy/Java que le couple Python/C.
En pratique on ne réécrit jamais de code Python en C, sauf parfois quelques bouts très critiques.