Pour moi, les destructeurs font partie du paradigme objet.
A ce niveau de non-justification c'est du troll. Il y a beaucoup de formalisations du "paradigme objet" différentes et elles se focalisent sur d'autres aspects plus fondamentaux (notion de méthodes ou bien de passage de message, héritage, etc.).
Mais bon, tu as le droit de dire que pour toi, les appuie-tête à motif léopard font partie du paradigme voiture.
Note que ta justification pour les destructeurs vient du fait que le langage implémente un système d'exceptions qui peuvent perturber le cours du programme à tout moment. Si le langage n'avait pas d'exceptions ou si leur implémentation était très différente, alors le besoin de finalisation automatique disparaîtrait. (mais peut-être que pour toi les exceptions aussi font partie du paradigme objet ;-)).
Je sais, mais à ce stade-là, soit il faut systématiquement mettre l'utilisation de tous tes objets dans des blocs passés au constructeurs
Là, ça tient de l'ignorance, puisque le système de blocs de ruby (de même que les fermetures en Python ou beaucoup d'autres langages) n'est pas limité à l'utilisation dans le cadre d'un constructeur. Dans l'exemple donné on devine bien que File.open est une banale méthode, pas un constructeur.
Du coup cela évite l'inconvénient du C++ où on doit créer de petits objets auxiliaires (des gardes, il me semble que c'est comme ça qu'on les appelle) gérant la finalisation d'une tâche menacée par des exceptions, parce qu'en C++ le seul moyen simple de faire de la finalisation est par le truchement d'un destructeur donc d'une désallocation d'un objet.
Plus fondamentalement cette utilisation de destructeurs pour la finalisation d'objet est assez criticable dans beaucoup de cas, car on ne voudra pas finaliser de la même façon selon qu'il y a eu une exception et que tout s'est bien passé. Par exemple, si je suis un serveur Web qui exécute un traitement CGI, je ne renverrai pas le même code de retour HTTP selon que le CGI termine bien ou qu'il me pète à la tronche. Donc les blocks try/except/finally sont souvent indispensables.
[^] # Re: Destructeurs
Posté par Antoine . En réponse à la dépêche Sortie de Ruby 1.8.5. Évalué à 6.
A ce niveau de non-justification c'est du troll. Il y a beaucoup de formalisations du "paradigme objet" différentes et elles se focalisent sur d'autres aspects plus fondamentaux (notion de méthodes ou bien de passage de message, héritage, etc.).
Mais bon, tu as le droit de dire que pour toi, les appuie-tête à motif léopard font partie du paradigme voiture.
Note que ta justification pour les destructeurs vient du fait que le langage implémente un système d'exceptions qui peuvent perturber le cours du programme à tout moment. Si le langage n'avait pas d'exceptions ou si leur implémentation était très différente, alors le besoin de finalisation automatique disparaîtrait. (mais peut-être que pour toi les exceptions aussi font partie du paradigme objet ;-)).
Je sais, mais à ce stade-là, soit il faut systématiquement mettre l'utilisation de tous tes objets dans des blocs passés au constructeurs
Là, ça tient de l'ignorance, puisque le système de blocs de ruby (de même que les fermetures en Python ou beaucoup d'autres langages) n'est pas limité à l'utilisation dans le cadre d'un constructeur. Dans l'exemple donné on devine bien que File.open est une banale méthode, pas un constructeur.
Du coup cela évite l'inconvénient du C++ où on doit créer de petits objets auxiliaires (des gardes, il me semble que c'est comme ça qu'on les appelle) gérant la finalisation d'une tâche menacée par des exceptions, parce qu'en C++ le seul moyen simple de faire de la finalisation est par le truchement d'un destructeur donc d'une désallocation d'un objet.
Plus fondamentalement cette utilisation de destructeurs pour la finalisation d'objet est assez criticable dans beaucoup de cas, car on ne voudra pas finaliser de la même façon selon qu'il y a eu une exception et que tout s'est bien passé. Par exemple, si je suis un serveur Web qui exécute un traitement CGI, je ne renverrai pas le même code de retour HTTP selon que le CGI termine bien ou qu'il me pète à la tronche. Donc les blocks try/except/finally sont souvent indispensables.