Image/Texture, Sprite et Drawable : remonter des méthodes

[Laurent]

Je suis pas spécialement convaincu, surtout parce que je ne vois pas en quoi sf::Drawable et sf::Transformable sont limitants.

Ils l'étaient dans SFML 1, ils ne le sont plus dans SFML 2, et ils le seraient à nouveau avec les changements proposés.

Je verrai probablement au fur et à mesure du temps, mais pour l'instant ça me convient très bien.

Donc on est d'accord sur le fait qu'il ne faut rien changer

C'est bien de vouloir tout permettre, mais c'est aussi bien de guider et garder les choses simples. Concevoir un design c'est pas instantané.

Oui mais j'ai eu tellement de problèmes avec SFML 1... j'insiste vraiment sur le fait que le design actuel est le fruit de l'expérience, pas de ma réflexion personnelle.

[Ceylo]

Je suis pas spécialement convaincu, surtout parce que je ne vois pas en quoi sf::Drawable et sf::Transformable sont limitants.

Ils l'étaient dans SFML 1, ils ne le sont plus dans SFML 2, et ils le seraient à nouveau avec les changements proposés.

Ah non mais je pensais pas spécialement aux changements proposés dans cette discussion . Ma question était un peu hors topic. J'ai vraiment rien à redire sur les sf::Drawable et sf::Transformable actuels, et c'est justement par rapport à eux (ceux dans la 2.0 RC) que je me demandais pourquoi tu ne voulais pas qu'on en hérite (ou j'ai mal compris ?).

[Laurent]

Oui, j'ai justement fait en sorte que ce ne soit plus gênant avec la nouvelle API, tout en gardant pas mal de simplicité.

[Lo-X]

Oui, j'ai justement fait en sorte que ce ne soit plus gênant avec la nouvelle API, tout en gardant pas mal de simplicité.

Et c'est très très bien comme ça ! J'ai pu continuer à utiliser la v2 comme la 1.6 et je viens juste de me mettre à utiliser les VertexArray, ça permet une progression. J'aurais été complètement paumé sinon 

[Ceylo]

Donc il n'y a plus de contre-indication à hériter de Drawable (et Transformable dans les cas utiles) .. ?

[Laurent]

Donc il n'y a plus de contre-indication à hériter de Drawable (et Transformable dans les cas utiles) .. ?

Tout à fait :
- sf::Drawable ne contient plus que la fonction Draw, et tout ce que ça fait c'est autoriser à écrire window.draw(mon_drawable) au lieu de, très probablement, mon_drawable.drawTo(window)
- sf::Transformable n'implémente plus que les transformations, il n'y a pas de fonction virtuelle ; c'est donc de l'héritage de réutilisation de code et non de polymorphisme, donc là encore aucun problème de design en vue

Ce qui me dérange encore c'est que comme les classes de SFML héritent toutes de sf::Drawable, les gens vont encore être tentés de faire des conteneurs<sf::Drawable*> ; mais comme il n'y a plus grand chose dans la classe, ça devrait les décourager suffisamment

[Ceylo]

Okok niquel alors .

[Bigz]

Ce qui me dérange encore c'est que comme les classes de SFML héritent toutes de sf::Drawable, les gens vont encore être tentés de faire des conteneurs<sf::Drawable*> ; mais comme il n'y a plus grand chose dans la classe, ça devrait les décourager suffisamment

Je me suis "fait avoir" avec ça. En partant tout benêt que j'étais sur une map <string, sf::Drawable*> pour au final me dire que c'était assez proche de l'inutile, et partir directement sur des collections de Sprite ou Vertices, selon les besoins.

[L01man]

Tu as raison : les prochaines fois, au lieu de poster sur le coup, je ferai des sujets plus concis, clairs, illustrés, etc. C'est vrai qu'on pourrait en discuter sans perdre de temps à se répéter ou mal se comprendre.
Pour finir, je suis d'accord quand Ceylo dit que la SFML a l'avantage d'un bon design, qui de base met sur une bonne voie. Sinon,  pourquoi utiliser le C++ et faire des classes ? Le C est idéal pour faire des toolbox qu'on peut utiliser dans tous les sens.
Et quand je parlais de casser les Sprite, etc. Je voulais dire les deshériter de Transformable, ce qui enlèverait l'héritage multiple, que n'a pas certains langages. Et remonter setColor et les autres ne créeraient aucun polymorphisme, ce sont juste des mutateurs et accesseurs de bases. En fait, je dis ça mais je n'en suis pas sur mais je ne trouve pas les fichiers .cpp dans la doc.