Le duck typing c'est du typage dynamique, vérifié uniquement à l'exécution. Ca peut devenir tres pénible qand tu as des grosses modifs à faire parce qu'il faut exécuter le programme et le faire passer par chaque branche pour voir si il se vautre pas sur une stupide erreur. Le refactoring ca peut surement aider dans certains cas, mais rien ne vaut une moulinette qui détecte les erreurs de facon 100% fiable.
Pour le coup du tableau en ruby, je suis peut etre fou, mais pourtant ce code ne génère pas d'erreur :
#!/usr/bin/ruby
array=[1,2]
print array[999]
#./test.rb
nil
Quand aux exceptions qui sont des classes je vois pas trop le probleme.
Ca doit etre surement moins couteux à l'execution et ca permet de vérifier le type d'erreur de maniere efficace et maintenable (en cas de renommage de l'exception le compilo te gueule dessus).
Je n'arrive pas à y voir d'inconvénient évident.
Ca va paraitre trollesque, mais quand je dois coder un truc dans ce genre de langages, j'ai un peu l'impression de faire un grand retour dans le temps à la glorieuse époque du VB6, sans le "OPTION EXPLICIT" bien sur
[^] # Re: Vendredi....OK, Target Locked ..... OK.... FIRE!
Posté par timid . En réponse à la dépêche Sortie de Moonlight 1.0. Évalué à 4.
Pour le coup du tableau en ruby, je suis peut etre fou, mais pourtant ce code ne génère pas d'erreur :
#!/usr/bin/ruby
array=[1,2]
print array[999]
#./test.rb
nil
Quand aux exceptions qui sont des classes je vois pas trop le probleme.
Ca doit etre surement moins couteux à l'execution et ca permet de vérifier le type d'erreur de maniere efficace et maintenable (en cas de renommage de l'exception le compilo te gueule dessus).
Je n'arrive pas à y voir d'inconvénient évident.
Ca va paraitre trollesque, mais quand je dois coder un truc dans ce genre de langages, j'ai un peu l'impression de faire un grand retour dans le temps à la glorieuse époque du VB6, sans le "OPTION EXPLICIT" bien sur