Pourquoi les composants sont des interfaces?

[nasso]

Pour moi, un composant n'est rien d'autre qu'une structure de donnée. Il n'y a pas d'"action" qu'on puisse faire ou faire faire un composant.

Pourquoi les composants ISprite, IAsciiSprite, IText etc... sont-ils des interfaces plutôt que de simples structures?

[Pebloop]

Parce que:

• Jérôme veut des interfaces
• ça permet une implémentation plus générale : Le sprite en lui même c'est un tableau de pixel mais la façon dont tu implémentes ce tableau est 100% libre, tu devras juste respecter une suite de méthodes getPixelAt(int index), getWidth() const, getHeigth() const, ...

Et comme tu ne peux pas créer une interface (vu que c'est abstrait) tu dois aussi créer une factory pour chacune d'entres elles.

[nasso]

Y a pleins de façons de l'implémenter tu veux dire

Exactement, et comme ici on traite de donnée pure, choisir sa représentation fait partie de l'API commune. Une structure de donnée fait complètement partie d'une API au même titre qu'une interface: il n'y a pas d'implémentation de logique (pour faire le parallèle, c'est dans les .h/.hpp qu'on définie les structures et la représentation des données).

Là tu imposes ta structure à tout le monde. Et c'est justement ce qu'il ne faut pas faire.

Je l'impose a personne, je fais un POC de mon côté sur quelque chose qu'on pourrait avoir. Ça permet d'évaluer la solution avant de la proposer. Jusque là j'ai trouvé cette solution comme étant la plus simple d'un point de vue utilisation et implémentation.

En ce qui concerne la lecture ça change rien parce que le core connait la classe derrière et peut donc faire ce qui lui chante.

C'est surtout la lib graphique qui va devoir lire les pixels pour les afficher!

[Pebloop]

Ok, j'ai regardé ton truc plus en détail et je vois le truc, ton sprite c'est pas un composant.
Or autant le transform je peux comprendre, c'est un peu indispensable, et c'est la base, autant le sprite reste un composant, tu peux avoir une entitée sans sprite et tu ne peux pas commencer à tout mettre dans un IEntity parce que tu dois pouvoir créer des comps facultatifs pour ceux qui veulent aller plus loin, d'où une liste de comp lisible.

Concernant la lecture... j'ai peut-être zappé le fait que c'est pas le core qui interprète les composants ?
Dans ce cas je peux comprendre l'idée d'utiliser une struct commune.
Je parlais d'inposer parce que techniquement si tu proposes une struct tout le monde est obligé d'avoir exactement la même, donc ça laisse 0 liberté, mais c'est vrai que lire une image pixel par pixel c'est chaud.

[nasso]

Mon sprite est 100% un composant.

Imposer une interface est exactement pareil qu'imposer une structure.

[Pebloop]

Non, c'est pas du tout pareil, son implémentation reste libre, c'est le principe même d'une interface

[nasso]

Quand ton interface prend un int en paramètre ou retourne un int, tu impose un int a tout le monde.

Remplace "int" par "structure".