C++0x et multi-method

Michael Doubez <michael.doubez@free.fr> writes:

[...]

| Voilà qui met un peu d'animation dans ce groupe.

ouais, c'était un peu morribond :-)

| C'est dommage qu'on sache déjà qu'il n'y aura pas de gagnant.

Ah, il devait y avoir un gagant ? :-p
(je ne pensais pas que c'était une compétition)

-- Gaby

Gabriel Dos Reis a écrit :

|
| Gaby nous l'ayant cité peut être dix fois,

Ton système arithmétique est remarquable.

je ne comptais pas que les citations dans /ce/ fil;
tu as déjà évoqué ce papier.

de plus il y a un /peut être/.

quant à mon système arithmétique, il se réduit à (0, 1, infini) donc
5 ou 15 ne font aucune différence.

note bien que je n'ai pas critiqué ici, le fait de citer ce papier,
mais au delà de la citation, s'y référer dans la discussion en cours
aurait pu être intéressant; tes réponses (de laconique à méprisante,
c'est selon qui les reçoit) n'ont été que "t'as pas lu le papier",
"on voit bien que t'as pas [lu | compris] le papier", je trouve ça
plutôt court et me fait constater une "histoire sans fin" où tu ne
veux discuter de rien sinon de ton papier ("ton": celui que tu as
choisi comme seul sujet valable).

Sylvain.

Sylvain SF <sylvain@boiteaspam.info> writes:

| Gabriel Dos Reis a écrit :
| > | | Gaby nous l'ayant cité peut être dix fois,
| >
| > Ton système arithmétique est remarquable.

[...]

| quant à mon système arithmétique, il se réduit à (0, 1, infini) donc
| 5 ou 15 ne font aucune différence.

très remarquable.

| note bien que je n'ai pas critiqué ici,

c'est noté mais je suis surpris par ta requête.

[...]

| veux discuter de rien sinon de ton papier ("ton": celui que tu as
| choisi comme seul sujet valable).

Ce qui est surprenant : le papier en question n'est pas mon sujet, mais
le sujet la discussion initiale, explicitement mentionné par la person ne
qui a lancé la discussion.

Je n'avais pas noté que c'était devenu un crime sur fr.comp.lang. c++ de
vouloir discuter du sujet spécific d'une discussion. C'est proche de
l'abracadabrantesque.

-- Gaby

On 31 mai, 12:12, ld <Laurent.Den...@gmail.com> wrote:

J'en profite pour expliquer (pas particulierement a toi ;-) un peu
plus en details pourquoi c'est aussi important d'un point de vu design
de software (mon lobbing). Je pense qu'une des erreurs de design de C+
+, c'est d'avoir mis les methodes virtual comme membre des classes.
Elles auraient du en rester a l'exterieur. Cela aurait permis:

- de garantir le Liskov Subtitution Principle au lieu de le violer
systematiquement. On sait aujourd'hui qu'il est pratiquement
impossible de le satisfaire en presence du runtime polymorphism. Cela
aurait aussi grandement simplifie la notion de classe et leur design.
Le runtime polymorphism venant apres, comme une extension de
l'interface selon les besoins.

Pourrais-tu détailler en quoi les mettre à l'extérieur aide au respec t
du LSP ? A priori, je ne vois pas trop le rapport.

--
Loïc

On 2 juin, 21:05, "loic.actarus.j...@numericable.fr"
<loic.actarus.j...@numericable.fr> wrote:

On 31 mai, 12:12, ld <Laurent.Den...@gmail.com> wrote:

> J'en profite pour expliquer (pas particulierement a toi ;-) un peu
> plus en details pourquoi c'est aussi important d'un point de vu design
> de software (mon lobbing). Je pense qu'une des erreurs de design de C+
> +, c'est d'avoir mis les methodes virtual comme membre des classes.
> Elles auraient du en rester a l'exterieur. Cela aurait permis:

> - de garantir le Liskov Subtitution Principle au lieu de le violer
> systematiquement. On sait aujourd'hui qu'il est pratiquement
> impossible de le satisfaire en presence du runtime polymorphism. Cela
> aurait aussi grandement simplifie la notion de classe et leur design.
> Le runtime polymorphism venant apres, comme une extension de
> l'interface selon les besoins.

Pourrais-tu détailler en quoi les mettre à l'extérieur aide au resp ect
du LSP ? A priori, je ne vois pas trop le rapport.

Parce que si les methodes (fonctions membres) virtuelles sont a
l'exterieur (non membre), les classes ne sont plus polymorphiques a
proprement parler (la resolution est externe et la portee de leurs
acces aussi). L'utilisation des classes devrait donc toujours passer
par leur interface (monomorphique+subtyping), et garantirait ainsi une
encapsulation forte sans redefinition de comportement: l'ennemi du LSP
et la raison d'etre des fonctions membres virtuelles. Si les classes
ne permettent plus le subclassing mais seulement le subtyping, il
devient beaucoup plus facile de respecter le LSP. CQFD ;-)

Certes, avec le CRTP on peut aussi ne pas respecter le LSP assez
facilement puisque le CRTP permet de simuler statiquement l'effet
rechercher avec les fonctions membres virtuelles. Ceci dit, c'est
aussi vrai avec les templates eux-memes (duck typing) mais je pense
que les concepts de C++0x devraient permettre de mieux maitriser leur
contexte d'utilisation et de limiter les abus.

Pour revenir au sujet initial, je disais que les open multi-methodes
(telles que descritent dans le papier) changeraient radicalement (en
bien) la facon de programmer en C++. Il faut voir les multi-methodes
comme des sortes de front-end permettant de passer la frontiere entre
le monde "externe" (dynamique, variable, inconnu a la compilation) au
monde "interne" (statique, fige, connu a la compilation). La
consequence du point de vue du design de soft, c'est que la separation
des deux mondes ne serait plus a l'interieur des hierarchies de
classes (abstraites) mais a l'exterieur avec un bien meilleur respect
du "separation of concern" (et du LSP) et un affaiblissement des
couplages entre les classes. En effet, une autre consequence de la
presence des multi-methodes, c'est que les hierarchies de classes
s'applatissent d'elle meme et le design est plus simple (et facile a
comprendre) parce que toutes les parties collaboratives sont definies
dans les open multi-methodes (i.e. roles dans l'architecture DCI). Et
programmer, c'est faire collaborer des entites avant tout... (*)

a+, ld.

(*) c'est ce qui fait que je suis toujours etonne de voir le peut
d'importance que l'on donne encore aujourd'hui aux multi-methodes. On
invente des tonnes de langages et de modeles de development alors que
les solutions (selon moi ;-) sont connues et simples (mais pas
fashion). C'est ce qui a motive le development de COS avec ce que
j'appelle son "inductive design" (principes => concepts) dans mon
papier.

ld <Laurent.Deniau@gmail.com> writes:

[...]

| (*) c'est ce qui fait que je suis toujours etonne de voir le peut
| d'importance que l'on donne encore aujourd'hui aux multi-methodes. On
| invente des tonnes de langages et de modeles de development alors que
| les solutions (selon moi ;-) sont connues et simples (mais pas
| fashion). C'est ce qui a motive le development de COS avec ce que
| j'appelle son "inductive design" (principes => concepts) dans mon
| papier.

Je crois que l'une des raisons est qu'il est plus facile d'implémenter
efficacement l'une que l'autre.

Je ne dirais pas qu'on accorde peu d'importance aux multi-méthodes, je
dirais qu'on les appelle autrement. Par exemple, dans Spad [1], la
programmation de base est à coup de multi-méthodes dans un certain
sens. De même certaines extensions populaires de Haskell [2] ont des
class de types multivariées.

Les implémentations *efficaces* de multi-méthodes sont un peu plu s dur à
realiser -- et on a quand même des problèmes d'ambiguité au runtime...

[1] http://www.open-axiom.org/
[2] http://www.haskell.org/

Gabriel Dos Reis a écrit :

Ce qui est surprenant : le papier en question n'est pas mon sujet, mais
le sujet la discussion initiale, explicitement mentionné par la personne
qui a lancé la discussion.

c'est en effet l'objet de la question initiale de "ld".
il me semble que tu as répondu clairement à sa question.
il me semble qu'ensuite tu n'as pas voulu parler d'autre chose que
des idées de ce papier lorsque échanges (de Mathias notamment) faisant,
le sujet s'était un peu élargi - ceci n'étant rien d'autre que ma
remarque précédente sur ta façon de fermer le débat.

mais ceci est un autre histoire sans fin et elle risque d'être
moins intéressante.

Sylvain.

Sylvain SF <sylvain@boiteaspam.info> writes:

[...]

| il me semble qu'ensuite tu n'as pas voulu parler d'autre chose que
| des idées de ce papier lorsque échanges (de Mathias notamment) faisant,

Je pense que sur ce point ton capteur d'impression nécessiterait
probablement un ajustement.

| le sujet s'était un peu élargi - ceci n'étant rien d'autre que ma
| remarque précédente sur ta façon de fermer le débat.

Je crois que ce serait un violent abus d'euphémisme que de dire
« le sujet s'était un peu élargi. »

| mais ceci est un autre histoire sans fin et elle risque d'être
| moins intéressante.

En effet.

-- Gaby

On 2 juin, 23:34, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:

ld <Laurent.Den...@gmail.com> writes:

[...]

| (*) c'est ce qui fait que je suis toujours etonne de voir le peut
| d'importance que l'on donne encore aujourd'hui aux multi-methodes. On
| invente des tonnes de langages et de modeles de development alors que
| les solutions (selon moi ;-) sont connues et simples (mais pas
| fashion). C'est ce qui a motive le development de COS avec ce que
| j'appelle son "inductive design" (principes => concepts) dans mon
| papier.

Je crois que l'une des raisons est qu'il est plus facile d'implémenter
efficacement l'une que l'autre.

Je ne dirais pas qu'on accorde peu d'importance aux multi-méthodes, je
dirais qu'on les appelle autrement.  Par exemple, dans Spad [1], la
programmation de base est à coup de multi-méthodes dans un certain
sens. De même certaines extensions populaires de Haskell [2] ont des
class de types multivariées.

Oui, je m'y suis interesse il y a 2-3 ans (au debut de COS) en meme
temps qu'a R (classes version 4) et qu'aux extensions des classes de
Haskell (via GHC). Mes conclusions etaient (si je me souviens bien):

- Spad (j'avais deja note ta participation active a ce projet) a ete
developpe des le depart avec une bonne comprehension de la flexibilite
qu'offraient les multi-methodes (organisation des categories) mais il
est trop specialise pour mon utilisation (et surtout pour mes
collegues de l'epoque). Et je ne connais pas sa rapidite par rapport a
C/C++. Mais l'approche me seduit beaucoup, je manque juste de temps
pour m'y mettre.

- R avait clairement pas anticipe l'evolution et le resultat est
confu, sans coherence apparente et du coup peu exploite (mon
impression), et plutot lent. Mais il a d'autres aspects (style
fonctionnel) que j'aime bien et qui fait que je l'utilise de temps en
temps (a la place de Matlab).

- Haskell 98 n'avait clairement pas anticipe les "multi-parameter type
classes" et du coup les classes sont mal organisees pour cette
extension, en particulier celles qui ont des operateurs binaires comme
Num. Je regarde de temps en temps Haskell' pour voir s'ils vont osez
tout changer et aussi limiter la portee des fonctions declarees dans
les classes: tres mauvaise idee de les rendre globales ce qui oblige
de definir les nouveaux operateurs avec des noms pas vraiment
naturels. Je surveille aussi le numeric prelude (au point mort) qui va
(essaye d'aller) dans la meme direction que Spad. De toute facon, je
ne pense pas que ce language soit encore assez mature pour mes
(futures) applications. Par exemple je n'ai aucne idee de comment
faire de la modelisation 3D (elements finis parametrises) en Haskell
de maniere efficace alors que la version C/C++/Fortran n'est deja pas
tres rapide et consomme plusieurs GB de memoire.

Les implémentations *efficaces* de multi-méthodes sont un peu plus du r à
realiser

Ca depend d'ou on part et ou on veut aller ;-) Celle de COS sont a peu
pres aussi rapide (+- 30%) que les fonctions membres virtuelles de C++
sur un CoreDuo2+Linux+gcc 4.3.3 (le a peu pres depend des classes
abstraites en C++). Tant que je suis dans un facteur deux, ca me va.
J'ai d'ailleurs vu que de gcc 4.1 a 4.2 (si je me souviens bien) les
fonctions membres virtuelles ont gagner presque un facteur deux en
rapidite d'appel (idem pour l'heritage virtuel).

-- et on a quand même des problèmes d'ambiguité au runtime...

Apres avoir jouer avec le C3, j'ai finalement opte pour une
linearisation des classes qui est non-ambigues, monotonique et
totalement ordonnee et tres simple a comprendre pour l'utilisateur
(c'est finalement le plus important). Sinon a chaque multi-methode
"generique" du type defmethod(void, doIt, Object, Object) on a une
ambiguite... Comme la linearisation est calculee lors de
l'initialisation de COS (runtime) et que je souhaite que cela reste de
l'ordre de quelques milli-secondes meme avec des dizaines de milliers
de methodes, elle doit etre tres rapide a calculer (je deteste les
demarrages poussifs des applis Java).

Je peux t'envoyer le dernier papier sur COS (12p) si tu veux, il donne
quelques details sur l'implementation (et une solution pour next-
method ;-). Mais a mon avis, la linearization proposee dans le papier
de BS est plus adaptee a C++ (pour plusieurs raisons, notament la
compatibilite avec l'ADL) et ce que fait COS n'est pas transposable au
C++ (et vice et versa, mais ca parait evident).

a+, ld.

ld <Laurent.Deniau@gmail.com> writes:

[...]

| Je peux t'envoyer le dernier papier sur COS (12p) si tu veux, il donne

oui, j'apprecierais beaucoup.
[ Je viens juste de sortir du service d'urgence et je vais être clou é au
lit pendant 2 ou 3 jours, donc je vais avoir un peu de temps pour lire
:-) ]

-- Gaby