iterator ; j2SE 1.5 ; enhanced for loop - Page 3

Moumou
:

Pollux :
Non, ça ne va pas bien du tout, tu ne peux pas importer un objet 3rd party déjà existant vers ce modèle (et pour cause, si l'objet est d'une classe dérivée de la classe 3rd party, il aura du mal à dériver aussi de ta classe extendée ^^)

Boah, il suffit de faire un constructeur par défaut pour ta classe dérivée, qui prend en entrée un argument de la classe originale

Mais non, ça peut pas marcher, tu peux pas transformer une String en DerivedString juste dans le constructeur, il peut y avoir des méthodes différentes, des champs en plus, etc (sans même parler de ce qui se passerait si tu re-passais ta classe à une lib 3rd-party, si par hasard elle essaye de regarder si ta String est bien une DerivedString ça va forcément foirer ^^)

Pollux :
Ben oui, c'est bien ce que je dis, mais justement, cette propriété évoluera *forcément* avec le temps, donc dire que "les types sont fixes si tu conçois bien ton programme" est complètement faux...

Pas si tu trouves les conditions non pas suffisantes, mais nécessaires

Idéalement elles devraient quand même être presque suffisantes (sinon autant tout faire avec des Object et lancer une exception si la méthode n'existe pas ou pour reprendre le cas du PGCD, c'est stupide d'avoir un algorithme qui accepte n'importe quel anneau mais ne termine pas si l'anneau ne vérifie pas certaines propriétés), du coup même les conditions nécessaires sont amenées à évoluer...

Pollux :
[EDIT : ah, je viens de relire ./24, et effectivement j'avais pas fait gaffe à la dernière phrase de Pen^2 : en effet soit on ne veut pas cacher le type et c'est juste une abréviation [publique et immuable] du vrai type, qui reste cependant connu de l'utilisateur de la classe, soit on veut cacher le type et alors il faut adopter ta solution -- enfin bref on parlait pas de la même chose ]

j'ai un peu perdu le fil depuis hier (nuit blanche en plus, du coup j'ai encore plus la flemme de tout lire tout de suite (dsl)), mais quand je parlais de *cacher* le type c'était pour ce genre de chose :

	#ifndef ARRAY2D_H
	#define ARRAY2D_H
	
	#include<vector>
	
	template<class T>
	class Array2D
	{
	public:
 	  inline Array2D(const unsigned int w,
 	         const unsigned int h,
 	         const T& v=T())
 	    : m_width(w),m_height(h),m_values(w*h,v)
 	    {
 	    }

	  typedef std::vector<T>::iterator iterator;              // !!
	  iterator begin() { return m_values.begin(); }         // !!
	  iterator end()   { return m_values.end();   }          // !!

 	private:
 	  unsigned int m_width,m_height;
 	  std::vector<T> m_values;
 	};
 	
 	#endif // ARRAY2D_H

=> l'utilisateur de la classe sait qu'il utilise un iterateur, mais il n'a pas besoin de savoir qu'il utilise un std::vector<T>::iterator : de son point de vue il utilisera un Array2D<TOTO>::iterator.


PS : exemple tiré de http://artis.imag.fr/~Xavier.Decoret/resources/stl_tutorial/conteneurs_part5.html

oui j'ai bien compris que tu faisais référence à l'usage qu'en fait la STL en C++, cela dit c'est discutable si comme dans le cas du C++ c'est pour masquer un détail d'implémentation interne qui pourrait éventuellement changer (par exemple si tu n'utilises plus un std::vector mais un std::foobarishvector) : je pense que la position de Moumou qui est de wrapper l'itérateur pour définir ton propre itérateur qui a une interface bien définie et que tu promets de ne pas changer est plus saine (par contre dans le cas de Java qui ne fait pas d'inlining, ça va entraîner une pénalité de performance :/), notamment parce que dans le cas contraire un utilisateur pourrait utiliser une méthode spécifique à std::vector<T>::iterator et qui n'est pas présente dans std::foobarishvector<T>::iterator, du coup ça casserait à la prochaine update de la bibliothèque...

en revanche là où le typedef est juste là comme une abréviation et pas pour masquer l'implémentation (par exemple, je sais pas, une Map pourrait avoir une fonction find() qui renvoie qqch de type FindResult, qui serait toujours une paire composée d'un itérateur et d'un booléen qui dit si la clé a été trouvée), ça ne pose pas de problème puisque le contenu exact de l'abréviation FindResult est connu de l'utilisateur, et qu'il ne changera jamais si l'implémentation change

Moui, c'est certain que si le type *caché* risque de changer, le wrapper avec une interface définitive est bien plus sûr. Mais je trouve un peu trop contraignant d'être obligé de passer par là dans tous les cas


'fin bref, je veux des typesdef (et les méthodes amies aussi ²) ()

Pen^2 :
Moui, c'est certain que si le type *caché* risque de changer, le wrapper avec une interface définitive est bien plus sûr. Mais je trouve un peu trop contraignant d'être obligé de passer par là dans tous les cas

Oui, définir une interface à la fois stable et flexible, c'est toujours contraignant, mais c'est nécessaire...

oui, mais ne pas avoir le choix de faire autrement pour certains cas particuliers, c'est un peu lourd (ceci dit, je n'ai pas l'air comme ça, mais en général, j'essaie de programmer proprement )