> J'en avais eu une : créer une classe de base dont le constructeur crée un
> finaliseur appelant une méthode considérée comme le destructeur,
> méthode à redéfinir sur les classes dérivées.
Oui, mais le problème concret c'est que ton finaliseur doit recevoir des paramètres (l'objet étant détruit il faut sauvegarder un contexte avant pour pouvoir se rappeler des valeur utiles). Or un système automatique ne pourra pas savoir de quelles noms d'attributs tu auras potentiellement besoin.
> D'autre part, les finaliseurs sont appelés après la destruction des objets !!!
> Là, je ne vois pas ce qui obligeait à une telle aberration...
C'est volontaire d'après ce que j'ai lu.
L'idée c'est :
- d'empêcher toute possibilité pour l'utilisateur de poser une référence de l'objet dans une variable externe (variable globale par exemple) pendant la destruction. Ca causerait très vite des "oops". D'après ce que j'ai lu ce problème existe en java (je n'ai pas vérifié).
- de limiter très fortement les destructeurs pour décourager les gens de les utiliser (partant du principe que la plupart des utilisations courantes sont des erreurs).
Le premier point est un choix que je peux comprendre mais c'est ce qui amène la "bizarrerie" des finaliseurs ruby. Le second point est pour moi une ahération (rendre volontairement complexe quelque chose n'a jamais été une bonne idée).
> Que répondre ?
> Tu pourras me démontrer que je peux m'en passer
Ce n'était pas mon but. C'était une vrai question, poussée par la curiosité.
> Si, comme je le crains, ça implique la destruction des destructeurs, je
> me rabattrai sur Python, même s'il est par ailleurs trop rigide à mon
> goût.
Je peux me tromper mais de mémoire python c'est un gc aussi, pas un compteur de ref.
[^] # Re: Destructeurs
Posté par Éric (site web personnel) . En réponse à la dépêche Ruby on rails 1.0 est sorti. Évalué à 2.
> finaliseur appelant une méthode considérée comme le destructeur,
> méthode à redéfinir sur les classes dérivées.
Oui, mais le problème concret c'est que ton finaliseur doit recevoir des paramètres (l'objet étant détruit il faut sauvegarder un contexte avant pour pouvoir se rappeler des valeur utiles). Or un système automatique ne pourra pas savoir de quelles noms d'attributs tu auras potentiellement besoin.
> D'autre part, les finaliseurs sont appelés après la destruction des objets !!!
> Là, je ne vois pas ce qui obligeait à une telle aberration...
C'est volontaire d'après ce que j'ai lu.
L'idée c'est :
- d'empêcher toute possibilité pour l'utilisateur de poser une référence de l'objet dans une variable externe (variable globale par exemple) pendant la destruction. Ca causerait très vite des "oops". D'après ce que j'ai lu ce problème existe en java (je n'ai pas vérifié).
- de limiter très fortement les destructeurs pour décourager les gens de les utiliser (partant du principe que la plupart des utilisations courantes sont des erreurs).
Le premier point est un choix que je peux comprendre mais c'est ce qui amène la "bizarrerie" des finaliseurs ruby. Le second point est pour moi une ahération (rendre volontairement complexe quelque chose n'a jamais été une bonne idée).
> Que répondre ?
> Tu pourras me démontrer que je peux m'en passer
Ce n'était pas mon but. C'était une vrai question, poussée par la curiosité.
> Si, comme je le crains, ça implique la destruction des destructeurs, je
> me rabattrai sur Python, même s'il est par ailleurs trop rigide à mon
> goût.
Je peux me tromper mais de mémoire python c'est un gc aussi, pas un compteur de ref.