Niels van Vliet <van-vl_n(a)lrde.epita.fr> writes:
Je n'aime pas les borders morphers :
- est-on sur de ce que ça fait (const cast) ?
- ce code est long pour pas grand chose.
- ce genre de fonction devrait peut-être être en interne.
wc border_morpher.hh
384 1251 11314
border_morpher.hh
et 6 classes pour un outils.
Encore une fois je ne suis pas fan de la logique
"un morpher pour une fonction".
Le patch est ok.
Oui le "const cast" est nécessaire, oui le code est long pour pas
grand chose... Ce n'est pas seulement le border morpher que tu remets
en cause mais tous les morphers (tu verras que les autres ont les
mêmes problèmes). A ces problèmes on peut ajouter (et non l'un des
moindres) le typage très long que doit écrire l'utilisateur d'un
morpher qu'il ne veut pas constant.
On ne veut pas utiliser "un morpher pour une fonction": juste quand
l'image morphée est une vue directe de l'image.
On peut discuter de:
- comment simplifier l'écriture des morphers ?
(en sachant que si on a 3 classes par morphers (super, const et non const),
c'est pour régler le problème du const et on ne peut pas vraiment y
échapper).
- comment simplifier l'utilisation des morphers non constants ?
(i.e. typage trop long)
- quand utiliser un morpher à bon escient ?
(à mon avis partout ou le résultat est une vue directe de l'entrée).
Pour les autres problèmes cités (l'inclusion d'integre par exemple),
tu as raison et je corrigerai.
--
Simon Odou
simon(a)lrde.epita.fr