Personne ne t'empêche de tester une idée dans un langage à typage "faible".
De plus c'est pas non plus super long d'écrire le type hein.
Ben c'est plus long que de ne pas l'indiquer
Il faut le mettre dans les declarations, dans les cast sans compter les
modificateurs à la pelle
On a inventé les génériques :
Pile maPile;
Quelle différence avec les templates C++
Tu es bien obligé de preciser le type d'objet lorsque tu l'utilises et donc tu as bien genéré un bytecode correspondant à ton "instanciation'"
Par exemple
List myIntList = new LinkedList(); // 1
myIntList.add(new Integer(0)); // 2
Integer x = (Integer) myIntList.iterator().next(); // 3
Tu généres en quelques sorte le bytecode de classe de ListInt.
Dans ma boîte on utilise massivement les templates C++ et je peux te garantir que ca dégrade pas mal les temps de compil, sans compter les problèmes de fabrication associés.Maintenant les genrerics en Java (depuis la 1.5 seulemen) je ne sais pas ce que ca donne
Mais n'importe quoi là ! Tu dis que c'est mieux d'avoir des piles de n'importe quoi, mais tu veux pas utiliser Object parcque ca apporte des erreurs ! Et ton n'importe quoi il va pas en apporter peut être ?
Ben justement avec un langage dynamique tu n'est pas obligé de passer par de tels artifices.
En Java tu peux aussi passer par des interfaces (plus propre conceptuellement) mais tu es de toute façon obligé de rajouter du code
(cf le lien sur la page de Bruce Eckel que j'ai donné)
Genre toi ....
Je te ferais remarquer que l'absence de typage fort et statique t'oblige à générer beaucoup plus de tests unitaires (puisqu'en gros tu dois te coltiner le boulot du compilo), ....
Absolument pas. Tu ne dois pas tester les types d'objets avec tes test unitaires
Tu définis un contrat qui est nettement plus rigoureux(précondition/postconditions , invariants) et va plus loin que la simple vérification de type.
Après tu valides le tout au moment de l'assemblage de tes composants.
Les test unitaires , ca sert uniquement à creer une suite de test et à t'assurer de la non régression.
C'est le contrat qui doit être exhaustif.
Autant le faire dès le début, ca sera toujours ca de fait. C'est comme .... et on code APRES.
cf . contrats
Enfin il faut pas assimiler la validation syntaxique à la compilation comme le fait Timaniac.
Mais si ! Ca fait parti du boulot du compilateur, c'est un fait dans la plupart des compilo. Point barre. C'est fou ca vouloir faire croire aux gens que la réalité est ailleur.
C'est une étape obligée pour pouvoir compiler mais ce n'est pas la finalité de la compilation.
Psycho c'est joli mais c'est x86 only, tu pers la portabilité, bref tu perds une grosse partie de l'intérêt d'un langage de haut niveau interprété, ce n'est donc pas une solution, juste un cache-misère pour faire croire que Python est portable, performant et enlarge ton penis.
C'est vrai que des projets comme gcj ca n'a aucun intêret c'est pour ca qu'il existent. Java ca roxe
Des trolls comme ca tu les gardes parce que moi aussi je peux jouer, genre:
En fait je comprends maintenant pourquoi on a besoin de super IDE
de la mort qui tue en Java et pas en Python
Parce faire du refactoring, tout recompiler=>(compli incrémentale), completer toutes les déclarations de type ... toussa il faut mettre les moyens pour retrouver de la productivité.
[^] # Re: Ruby On Rails
Posté par golum . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 2.
Personne ne t'empêche de tester une idée dans un langage à typage "faible".
De plus c'est pas non plus super long d'écrire le type hein.
Ben c'est plus long que de ne pas l'indiquer
Il faut le mettre dans les declarations, dans les cast sans compter les
modificateurs à la pelle
On a inventé les génériques :
Pile maPile;
Quelle différence avec les templates C++
Tu es bien obligé de preciser le type d'objet lorsque tu l'utilises et donc tu as bien genéré un bytecode correspondant à ton "instanciation'"
Par exemple
List myIntList = new LinkedList(); // 1
myIntList.add(new Integer(0)); // 2
Integer x = (Integer) myIntList.iterator().next(); // 3
Tu généres en quelques sorte le bytecode de classe de ListInt.
Dans ma boîte on utilise massivement les templates C++ et je peux te garantir que ca dégrade pas mal les temps de compil, sans compter les problèmes de fabrication associés.Maintenant les genrerics en Java (depuis la 1.5 seulemen) je ne sais pas ce que ca donne
Mais n'importe quoi là ! Tu dis que c'est mieux d'avoir des piles de n'importe quoi, mais tu veux pas utiliser Object parcque ca apporte des erreurs ! Et ton n'importe quoi il va pas en apporter peut être ?
Ben justement avec un langage dynamique tu n'est pas obligé de passer par de tels artifices.
En Java tu peux aussi passer par des interfaces (plus propre conceptuellement) mais tu es de toute façon obligé de rajouter du code
(cf le lien sur la page de Bruce Eckel que j'ai donné)
Genre toi ....
Je te ferais remarquer que l'absence de typage fort et statique t'oblige à générer beaucoup plus de tests unitaires (puisqu'en gros tu dois te coltiner le boulot du compilo), ....
Absolument pas. Tu ne dois pas tester les types d'objets avec tes test unitaires
Tu définis un contrat qui est nettement plus rigoureux(précondition/postconditions , invariants) et va plus loin que la simple vérification de type.
Après tu valides le tout au moment de l'assemblage de tes composants.
Les test unitaires , ca sert uniquement à creer une suite de test et à t'assurer de la non régression.
C'est le contrat qui doit être exhaustif.
Autant le faire dès le début, ca sera toujours ca de fait. C'est comme .... et on code APRES.
cf . contrats
Enfin il faut pas assimiler la validation syntaxique à la compilation comme le fait Timaniac.
Mais si ! Ca fait parti du boulot du compilateur, c'est un fait dans la plupart des compilo. Point barre. C'est fou ca vouloir faire croire aux gens que la réalité est ailleur.
C'est une étape obligée pour pouvoir compiler mais ce n'est pas la finalité de la compilation.
Psycho c'est joli mais c'est x86 only, tu pers la portabilité, bref tu perds une grosse partie de l'intérêt d'un langage de haut niveau interprété, ce n'est donc pas une solution, juste un cache-misère pour faire croire que Python est portable, performant et enlarge ton penis.
C'est vrai que des projets comme gcj ca n'a aucun intêret c'est pour ca qu'il existent. Java ca roxe
Des trolls comme ca tu les gardes parce que moi aussi je peux jouer, genre:
En fait je comprends maintenant pourquoi on a besoin de super IDE
de la mort qui tue en Java et pas en Python
Parce faire du refactoring, tout recompiler=>(compli incrémentale), completer toutes les déclarations de type ... toussa il faut mettre les moyens pour retrouver de la productivité.