La préconisation d'[Herb Sutter] est d’élargir au maximum l’interface des classes par l’extérieur et de garder membres uniquement les fonctions qui ont besoin d’aller taper dans les membres privés, ou qui peuvent être supplantées par redéfinition (overridding en VO).
C'est typiquement pas le cas des méthodes size() et data() (pour empty() on peut l'implémenter à partir de size() si la complexité de cette dernière est constante).
C'est vrai, et c'est là que j'aime bien le commentaire d'Alexander Stepanov qui dit que size() aurait dû être une fonction externe et amie.
D'un point de vue de la syntaxe, c'est un peu plus compliqué que cela. Dire que a.f(b), b.f(a) et f(a, b) n'est qu'une convention, c'est aller un peu vite... Écrire myValue.addTo(myArray) choque tout le monde quelque soit le langage.
Presque. Je dis que a.f(b), f(a, b), ou (f a b) ce n'est qu'une convention d'écriture. Un sucre syntaxique.
Quand je parle de la validité de a.f(b) ou de b.f(a) c'est dans un contexte de dispatch multiple. L'écriture o.f() est intéressante dans nos langages pour dispatcher l'appel à la bonne fonction f() en fonction du type dynamique exact de l'objet o. Mais quand le dispatch dépend du type dynamique de plusieurs objets, pourquoi en choisir un plutôt qu'un autre? On aura parfois, souvent ?, un verbe qui rend un appel plus clair, mais pas toujours. Un exemple type de dispatch multiple : la gestion de collision entre plusieurs objets de natures différentes (vaisseau, missile, astéroïde...). Dans la collision il n'y a pas un objet qui soit plus acteur qu'un autre.
D'un point de vu pratique il n'est pas pratique d'avoir de l'autocomplétion sur des méthodes libres.
Il est vrai que la complétion sur des fonctions libres peut s'avérer moins pratique car le lexique des fonctions libres et plus conséquent—même en restreignant le périmètre à toutes les fonctions pouvant matcher des variables dans la portée courante. Si mes souvenirs sont bons, ce point était ressorti lors des échanges autour de l'UCS. Mais il n'avait pas été considéré comme
critique.
D'un point de vu lecture, le chainage est plus compliqué de mon point de vu :
Le chainage o.f().g() respire la vilaine violation de la Loi de Déméter j'ai envie de dire. Quitte à enchainer des transformations de données, je préfère ce qui est fait dans les ranges v3: o | f() | g().
Je ne suis pas sûr de te suivre concernant ta remarque sur le structural binding. Les concepts ça reste du polymorphisme statique. Dans le cas du dispatch multiple OO, nous sommes sur du polymorphisme dynamique.
[^] # Re: Hum hum...
Posté par lmg HS (site web personnel) . En réponse à la dépêche C++17 libère size(), data() et empty(). Évalué à 3.
C'est vrai, et c'est là que j'aime bien le commentaire d'Alexander Stepanov qui dit que
size()aurait dû être une fonction externe et amie.Presque. Je dis que
a.f(b),f(a, b), ou(f a b)ce n'est qu'une convention d'écriture. Un sucre syntaxique.Quand je parle de la validité de
a.f(b)ou deb.f(a)c'est dans un contexte de dispatch multiple. L'écritureo.f()est intéressante dans nos langages pour dispatcher l'appel à la bonne fonctionf()en fonction du type dynamique exact de l'objeto. Mais quand le dispatch dépend du type dynamique de plusieurs objets, pourquoi en choisir un plutôt qu'un autre? On aura parfois, souvent ?, un verbe qui rend un appel plus clair, mais pas toujours. Un exemple type de dispatch multiple : la gestion de collision entre plusieurs objets de natures différentes (vaisseau, missile, astéroïde...). Dans la collision il n'y a pas un objet qui soit plus acteur qu'un autre.Il est vrai que la complétion sur des fonctions libres peut s'avérer moins pratique car le lexique des fonctions libres et plus conséquent—même en restreignant le périmètre à toutes les fonctions pouvant matcher des variables dans la portée courante. Si mes souvenirs sont bons, ce point était ressorti lors des échanges autour de l'UCS. Mais il n'avait pas été considéré comme
critique.
Le chainage
o.f().g()respire la vilaine violation de la Loi de Déméter j'ai envie de dire. Quitte à enchainer des transformations de données, je préfère ce qui est fait dans les ranges v3:o | f() | g().Je ne suis pas sûr de te suivre concernant ta remarque sur le structural binding. Les concepts ça reste du polymorphisme statique. Dans le cas du dispatch multiple OO, nous sommes sur du polymorphisme dynamique.