[FAQ] [conception] on a les sémantiques de valeur, d'entité . . . et de collection ?

Version imprimable

29/01/2016, 17h37
koala01

[FAQ] [conception] on a les sémantiques de valeur, d'entité . . . et de collection ?
Salut,

On insiste de plus en plus sur les sémantiques de valeur et d'entité, et on a bien raison de le faire. Mais on se pose régulièrement la question de "mais quelle est la sémantique d'une collection" :question:

Alors, je sais que le terme n'existe pas (encore), mais, je me demande sincèrement si nous ne devrions pas commencer à introduire le concept de "sémantique de collection", étant donné qu'il s'agit d'un concept totalement séparé de celui des deux sémantiques dont on parle généralement.

Je m'explique : on a dans la FAQ une entrée sur la sémantique de valeur et une autre sur la sémantique d'entité

Ne pourrait-on pas introduire une nouvelle entrée proche de
Citation:
Q quand est-ce qu'une classe a sémantique de collection

R On dit d'une classe qu'elle a sémantique de collection quand son objectif est de maintenir un certain nombre d'éléments d'un type particulier en permettant à l'utilisateur d'y accéder séparément ou de manière groupée.

Cette sémantique particulière prend place exactement entre les sémantiques de valeur et d'entité dont elle recouvre certaines de leur caractéristiques, mais présente également certaines particularités qui lui sont propres :

il est possible qu'elle soit destinée à servir dans une relation d'héritage, tout comme il est possible qu'elle ne le soit pas
elle fournit généralement la possibilité d'ajouter, de rechercher et de supprimer un (ou plusieurs) élément(s) particulier
elle fournit au minimum la possibilité d'accéder en lecture seule à un élément particulier parmi ceux qu'elle contient
elle peut fournir la possibilité d'accéder à un élément particulier parmi celle qu'elle contient afin de modification

La capacité que l'utilisateur a de copier un objet ayant sémantique de collection et / ou d'affecter un tel objet à un autre (via le constructeur de copie et l'opérateur d'affectation) dépend essentiellement de la sémantique des éléments qu'elle contient : si elle contient des éléments dont le type a sémantique de valeur, la copie et l'affectation seront possibles, mais si elle contient des éléments dont le type a sémantique d'entité, ni l'un ni l'autre ne seront possibles.
Bien sur, ce n'est qu'un "premier jet" et comme il s'agit d'inventer le concept, la "mayonnaise pourrait ne pas prendre". Mais, que pensez vous de cette idée :question:
29/01/2016, 19h15
Invité

Du moment que ça s'applique au int[42][42], ça me va.
Ça va, je plaisante...

Dans la STL, le concept de conteneur est couplé au concept d'itérateur (http://en.cppreference.com/w/cpp/concept/Container) et c'est pas mal pratique au final.
Du coup, il faudrait peut-être également définir les deux sémantiques; à moins que ce ne soit une vision trop bas niveau pour de la sémantique.
31/01/2016, 12h11
ternel
A mon sens, il n'y a pas de sémantique propre à la collection.

Une collection a deux formes très différentes:
- une classe technique, telle que vector, string ou map (et toute la stl), qui permet de factoriser du code bassement technique (buffer, indexation, etc)
- une classe métier, qui a pour role de regrouper des choses de manière simple pour les considérations métier.
La première forme a clairement une sémantique de valeur, même si c'est une valeur composite.
Ca n'est pas différent d'un code couleur, constitué de trois composantes (rouge, vert, bleu) ou d'un nombre complexe, dont on peut déterminer la partie réelle ou la norme.
Comme les valeurs, il est parfaitement pertinent de comparer deux std::vector et de les considérer identiques s'ils ont le même contenu.
Les différentes classes de collections de la stl n'ont pas de sens propre, si ce n'est leurs spécifications de performances.
C'est d'ailleurs la raison pour laquelle nous avons des opérateurs de comparaisons et des itérateurs dans chaque classe de la STL.

Ce type de classes n'est pas limité à la STL, par exemple, Boost en propose d'autres, comme les bimap ou les multi indexed map.

A l'opposé, les collections métiers ne sont pas vraiment comparable.
La bibliothèque d'une ville est différente de celle d'une autre ville. Même si par hasard, elles avaient des exemplaires des mêmes documents, et les mêmes clients, etc.
Bien sûr, à l'usage, ce sont des collections de livres empruntables, mais l'utilisateur n'y ajoute ou n'y retire rien tout seul.

Ces collections-là sont des entités, et j'ai le sentiment qu'elles contiennent en général des entités.

Si vraiment on tient à définir la sémantique d'une collection, je serai d'avis qu'une collection à la même nature sémantique que son contenu.
Pour reprendre ma métaphore, les livres d'une bibliothèques sont des entités: les exemplaires d'une même œuvre sont des objets distincts.
01/02/2016, 08h53
Luc Hermitte

AMA, on est plus dans le concept (cf la doc de la STL -- je parle bien de la STL et pas de la SL) que dans la sémantique si on veut catégoriser les collections.

En C++, la sémantique de valeur a un petit côté bâtard. Tous les trucs à sémantique de valeur (copiable, affectable, et à strictement parler comparables) sont mutables en C++ -- ou du moins, c'est très souvent le cas. Choses que l'on n'a pas avec les value-objects en Java p.ex. Les chaines et autres collections sont mutables. Ce qui fait qu'au delà de la comparaison de valeur, elles acquièrent très vite une identité -- et c'est encore plus orienté identité quand elles deviennent métier comme l'a souligné leternel.
Avant de chercher la sémantique des collections, j'aurai plutôt vu les exceptions. Et puis aussi les objets réguliers (valeur + ordre). Voire les objets qui appartiennent à des anneaux/groupes (tous les trucs mathématiques). Mais il est vrai que les collections ont ce status bâtard en C++.

Mais a trop vouloir catégoriser, je me demande si tout simplement il ne faut pas introduire les concepts. Les concepts nous disent qui est censé définir quoi. La dichotomie entité/valeur nous dit qui a besoin de définir ou interdire quelles opérations de copies.
01/02/2016, 09h19
ternel

Question sondage, il manquerait une réponse du type "Non, je pense que les collections ne sont pas une autre sémantique".
Je ne suis pas d'accord avec la proposition, mais je ne pense pas non plus que ce soit "bien assez compliqué comme ca"
01/02/2016, 09h33
Iradrille
Citation:

Envoyé par leternel

Question sondage, il manquerait une réponse du type "Non, je pense que les collections ne sont pas une autre sémantique".
Je ne suis pas d'accord avec la proposition, mais je ne pense pas non plus que ce soit "bien assez compliqué comme ca"

+1, et mon vote "non" est à comprendre comme ça.

Collection et valeur / entité, c'est 2 niveaux différents.

Comme le dit leternel une collection peut avoir sémantique de valeur ou d'entité.

Puis ya les cas bizarre aussi.
Code:

1 2 3 4 struct POD { int i, j; }; POD o0; // sémantique de valeur POD o1[1]; // sémantique de valeur ? collection ?
01/02/2016, 10h56
stendhal666
Citation:

Cette sémantique particulière prend place exactement entre les sémantiques de valeur et d'entité dont elle recouvre certaines de leur caractéristiques, mais présente également certaines particularités qui lui sont propres :

Contradiction entre: elle prend place "exactement entre" mais elle "recouvre certaines de leurs caractéristiques", c'est soit l'un soit l'autre si on s'exprime rigoureusement

Citation:

il est possible qu'elle soit destinée à servir dans une relation d'héritage, tout comme il est possible qu'elle ne le soit pas

soit A, soit non A: soit c'est une tautologie soit cela veut dire qu'il n'y a pas de règle concernant la participation à l'héritage. Pourtant, la plupart des conteneurs de la STL sont destinés à ne pas servir dans une relation d'héritage, ce qui contrevient plutôt à cette définition (ne pas à être destiné à être A != être destiné à ne pas être A)

Citation:

elle fournit généralement la possibilité d'ajouter, de rechercher et de supprimer un (ou plusieurs) élément(s) particulier

ce qui m'embête avec le "généralement" c'est qu'il n'a généralement ( :) ) pas sa place dans une définition, c'est plutôt un commentaire, parce qu'il ne permet pas de classer avec certitude dans ou hors d'une catégorie.

Citation:

elle fournit au minimum la possibilité d'accéder en lecture seule à un élément particulier parmi ceux qu'elle contient

Ce qui est vrai de presque tous les objets composites, même de ceux à qui on ne donnerait pas spontanément le titre de collection. Un point x, y est il une collection de l'ordonnée et de l'abscisse?

Code:

elle peut fournir la possibilité d'accéder à un élément particulier parmi celle qu'elle contient afin de modification

on en revient à "la possibilité d'ajouter, de rechercher et de supprimer" puisque modifier équivaut à insérer après modification un élément retiré, non?

Citation:

Dans la STL, le concept de conteneur est couplé au concept d'itérateur

Il y a quand même le bitset qui échappe à cette règle, non? Plus généralement conteneur != collection, puisque pair et tuple sont clairement des collections et pas des conteneurs

Quelques remarques de mon cru:
- le concept de collection est à mon avis étranger au C++. Le choix de la STL c'est justement de découpler les conteneurs et les algorithmes en plaçant les itérateurs au milieu. La généralisation de l'itérateur serait plutôt la séquence (range: cf Alexandrescu on iteration http://www.informit.com/articles/article.aspx?p=1407357 , si on est d'accord avec lui).
- dans la conception C++/STL, une collection pourrait être du point de vue conceptuel, c'est-à-dire de l'algorithme, tantôt une valeur "insécable" tantôt un "iterable": une matrice est un bon exemple puisque l'algorithme de multiplication la verra comme une paire d'itérateurs (sur des itérateurs, c'est la nature de matrice[i][j] par exemple) mais un algorithme générique comme le GCD ou la puissance la verrait comme l'élément d'un demi-groupe ou d'un demi-anneau. Il me semble donc qu'elle ne constitue pas une sémantique à part entière.
- en revanche, la classification des itérateurs qui est faite dans la STL pèche d'un point de vue sémantique (cf confusion entre la sémantique d'accès et la sémantique de déplacement qui devrait être découplée, comme c'est fait dans Boost::iterator), ce serait plutôt dans cette direction qu'une FAQ devrait informer des risques contenus dans la dangereuse proximité lexicale entre forward_iterator et input_iterator par exemple
Au total, s'il fallait définir la collection pour qu'elle corresponde à l'intuition générale du concept, je dirais que c'est un contenant étranger à son contenu, dans le sens où un Point (x, y) n'est pas étranger à ses coordonnées mais qu'une paire (x, y) l'est. En C++, le sens que cela peut prendre est difficile à définir: par exemple: template <class T> using Point = std::pair<T, T>; ne crée qu'un alias, pas un type différent et on pourra continuer à utiliser std::pair à la seule condition que les deux éléments qu'elle contient soit de même type: il n'y a pas de support du langage pour discriminer la sémantique de collection et d'objet. En Haskell, par exemple on peut créer un nouveau type à partir d'un type existant avec newtype et les deux types (pourtant strictement identiques) ne seront plus substituables. On pourrait peut-être faire cela En C++ avec des enveloppes template du genre
Code:

1 2 3 4 5 6 template <typename T> struct New_type { T value; explicit New_type(const T& v) : value(v) {} // constructeurs explicites ou deleted explicit operator T() { return value; }
};

mais je ne sais pas où cela pourrait mener
01/02/2016, 19h54
Invité

Citation:

Envoyé par stendhal666

En C++, le sens que cela peut prendre est difficile à définir: par exemple: template <class T> using Point = std::pair<T, T>; ne crée qu'un alias, pas un type différent et on pourra continuer à utiliser std::pair à la seule condition que les deux éléments qu'elle contient soit de même type: il n'y a pas de support du langage pour discriminer la sémantique de collection et d'objet. En Haskell, par exemple on peut créer un nouveau type à partir d'un type existant avec newtype et les deux types (pourtant strictement identiques) ne seront plus substituables. On pourrait peut-être faire cela En C++ avec des enveloppes template du genre...

Je ne suis pas expert en Haskell mais il me semble qu'avec newtype tu crées un nouveau type algébrique qui "encapsule" une valeur du type initial dans un constructeur de type. Donc la valeur encapsulée est effectivement du type initial mais le nouveau type est bel et bien différent, d'où la substitution impossible. Ramené à la POO, le newtype d'Haskell correspond donc plutôt à une déclaration de classe en C++ (comme l'indique ton exemple d'ailleurs) et c'est plutôt le type qui correspondrait au using.
Cela dit, je trouve la comparaison avec Haskell assez intéressante; d'ailleurs Haskell propose des classes de types pour différentes structures: semi-groupe, monoïde, foncteur...