Est-ce que quelqu'un sait s'il y a une chance que les "open multi-
methods" proposees par B.S. et al. (a GPCE'07) ont une chance d'etre
dans C++0x? Pour l'instant je n'y vois aucune allusion et je sais que
cela demande un changement significatif du modele objet (frein a son
adoption?). Pourtant ca changerait enormement les possibilites
"dynamiques" de C++.
Est-ce que quelqu'un sait s'il y a une chance que les "open multi- methods" proposees par B.S. et al. (a GPCE'07) ont une chance d'etre dans C++0x? Pour l'instant je n'y vois aucune allusion et je sais que cela demande un changement significatif du modele objet (frein a son adoption?). Pourtant ca changerait enormement les possibilites "dynamiques" de C++.
a+, ld.
Je ne pense pas. Normalement, la liste des ajouts est +- gelée, et il est probablement hors de question d'introduire un changement "bouleversant" aussi tard dans le processus, sans que l'on en entende parler qui plus est.
On 29 mai, 18:02, ld <Laurent.Den...@gmail.com> wrote:
Est-ce que quelqu'un sait s'il y a une chance que les "open multi-
methods" proposees par B.S. et al. (a GPCE'07) ont une chance d'etre
dans C++0x? Pour l'instant je n'y vois aucune allusion et je sais que
cela demande un changement significatif du modele objet (frein a son
adoption?). Pourtant ca changerait enormement les possibilites
"dynamiques" de C++.
a+, ld.
Je ne pense pas. Normalement, la liste des ajouts est +- gelée, et il
est probablement hors de question d'introduire un changement
"bouleversant" aussi tard dans le processus, sans que l'on en entende
parler qui plus est.
Est-ce que quelqu'un sait s'il y a une chance que les "open multi- methods" proposees par B.S. et al. (a GPCE'07) ont une chance d'etre dans C++0x? Pour l'instant je n'y vois aucune allusion et je sais que cela demande un changement significatif du modele objet (frein a son adoption?). Pourtant ca changerait enormement les possibilites "dynamiques" de C++.
a+, ld.
Je ne pense pas. Normalement, la liste des ajouts est +- gelée, et il est probablement hors de question d'introduire un changement "bouleversant" aussi tard dans le processus, sans que l'on en entende parler qui plus est.
Mathias Gaunard
On 29 mai, 18:02, ld wrote:
Est-ce que quelqu'un sait s'il y a une chance que les "open multi- methods" proposees par B.S. et al. (a GPCE'07) ont une chance d'etre dans C++0x? Pour l'instant je n'y vois aucune allusion et je sais que cela demande un changement significatif du modele objet (frein a son adoption?). Pourtant ca changerait enormement les possibilites "dynamiques" de C++.
Ce n'est pas prévu, non. Plusieurs alternatives sont néanmoins possibles pour avoir ce genre de fonctionnalités :
1) utiliser des variants (i.e. boost variant et son système de visiteurs) 2) faire un environnement de duck typing, ce qui revient en fait à modéliser les objets par des tableaux associatifs de chaînes de caractères vers des objets qui peuvent eux-mêmes êtres des fonctions. Reviens en fait au 1) avec deux-trois cas.
On 29 mai, 18:02, ld <Laurent.Den...@gmail.com> wrote:
Est-ce que quelqu'un sait s'il y a une chance que les "open multi-
methods" proposees par B.S. et al. (a GPCE'07) ont une chance d'etre
dans C++0x? Pour l'instant je n'y vois aucune allusion et je sais que
cela demande un changement significatif du modele objet (frein a son
adoption?). Pourtant ca changerait enormement les possibilites
"dynamiques" de C++.
Ce n'est pas prévu, non.
Plusieurs alternatives sont néanmoins possibles pour avoir ce genre de
fonctionnalités :
1) utiliser des variants (i.e. boost variant et son système de
visiteurs)
2) faire un environnement de duck typing, ce qui revient en fait à
modéliser les objets par des tableaux associatifs de chaînes de
caractères vers des objets qui peuvent eux-mêmes êtres des fonctions.
Reviens en fait au 1) avec deux-trois cas.
Est-ce que quelqu'un sait s'il y a une chance que les "open multi- methods" proposees par B.S. et al. (a GPCE'07) ont une chance d'etre dans C++0x? Pour l'instant je n'y vois aucune allusion et je sais que cela demande un changement significatif du modele objet (frein a son adoption?). Pourtant ca changerait enormement les possibilites "dynamiques" de C++.
Ce n'est pas prévu, non. Plusieurs alternatives sont néanmoins possibles pour avoir ce genre de fonctionnalités :
1) utiliser des variants (i.e. boost variant et son système de visiteurs) 2) faire un environnement de duck typing, ce qui revient en fait à modéliser les objets par des tableaux associatifs de chaînes de caractères vers des objets qui peuvent eux-mêmes êtres des fonctions. Reviens en fait au 1) avec deux-trois cas.
ld
On 30 mai, 01:32, Mathias Gaunard wrote:
On 29 mai, 18:02, ld wrote:
> Est-ce que quelqu'un sait s'il y a une chance que les "open multi- > methods" proposees par B.S. et al. (a GPCE'07) ont une chance d'etre > dans C++0x? Pour l'instant je n'y vois aucune allusion et je sais que > cela demande un changement significatif du modele objet (frein a son > adoption?). Pourtant ca changerait enormement les possibilites > "dynamiques" de C++.
Ce n'est pas prévu, non. Plusieurs alternatives sont néanmoins possibles pour avoir ce genre de fonctionnalités :
1) utiliser des variants (i.e. boost variant et son système de visiteurs)
les variants sont purement static (il n'y a pas de "type erasure"), ca ne peut donc pas marcher. Il faudrait plutot quelque chose base sur boost any qui lui est dynamique. Mais les tentatives sont tres lourdes, tres lentes et pas vraiment convainquantes.
2) faire un environnement de duck typing,
oui, de dynamic duck typing.
ce qui revient en fait à modéliser les objets par des tableaux associatifs de chaînes de caractères vers des objets qui peuvent eux-mêmes êtres des fonction s.
le typeid serait plus efficace mais de toute facon cela ne convient pas non plus puisque ca ne gerera pas l'heritage. Et les solutions basees sur dynamic_cast seront tres lentes.
a+, ld.
On 30 mai, 01:32, Mathias Gaunard <loufo...@gmail.com> wrote:
On 29 mai, 18:02, ld <Laurent.Den...@gmail.com> wrote:
> Est-ce que quelqu'un sait s'il y a une chance que les "open multi-
> methods" proposees par B.S. et al. (a GPCE'07) ont une chance d'etre
> dans C++0x? Pour l'instant je n'y vois aucune allusion et je sais que
> cela demande un changement significatif du modele objet (frein a son
> adoption?). Pourtant ca changerait enormement les possibilites
> "dynamiques" de C++.
Ce n'est pas prévu, non.
Plusieurs alternatives sont néanmoins possibles pour avoir ce genre de
fonctionnalités :
1) utiliser des variants (i.e. boost variant et son système de
visiteurs)
les variants sont purement static (il n'y a pas de "type erasure"), ca
ne peut donc pas marcher. Il faudrait plutot quelque chose base sur
boost any qui lui est dynamique. Mais les tentatives sont tres
lourdes, tres lentes et pas vraiment convainquantes.
2) faire un environnement de duck typing,
oui, de dynamic duck typing.
ce qui revient en fait à
modéliser les objets par des tableaux associatifs de chaînes de
caractères vers des objets qui peuvent eux-mêmes êtres des fonction s.
le typeid serait plus efficace mais de toute facon cela ne convient
pas non plus puisque ca ne gerera pas l'heritage. Et les solutions
basees sur dynamic_cast seront tres lentes.
> Est-ce que quelqu'un sait s'il y a une chance que les "open multi- > methods" proposees par B.S. et al. (a GPCE'07) ont une chance d'etre > dans C++0x? Pour l'instant je n'y vois aucune allusion et je sais que > cela demande un changement significatif du modele objet (frein a son > adoption?). Pourtant ca changerait enormement les possibilites > "dynamiques" de C++.
Ce n'est pas prévu, non. Plusieurs alternatives sont néanmoins possibles pour avoir ce genre de fonctionnalités :
1) utiliser des variants (i.e. boost variant et son système de visiteurs)
les variants sont purement static (il n'y a pas de "type erasure"), ca ne peut donc pas marcher. Il faudrait plutot quelque chose base sur boost any qui lui est dynamique. Mais les tentatives sont tres lourdes, tres lentes et pas vraiment convainquantes.
2) faire un environnement de duck typing,
oui, de dynamic duck typing.
ce qui revient en fait à modéliser les objets par des tableaux associatifs de chaînes de caractères vers des objets qui peuvent eux-mêmes êtres des fonction s.
le typeid serait plus efficace mais de toute facon cela ne convient pas non plus puisque ca ne gerera pas l'heritage. Et les solutions basees sur dynamic_cast seront tres lentes.
a+, ld.
Gabriel Dos Reis
ld writes:
| Est-ce que quelqu'un sait s'il y a une chance que les "open multi- | methods" proposees par B.S. et al. (a GPCE'07) ont une chance d'etre | dans C++0x? Pour l'instant je n'y vois aucune allusion et je sais que | cela demande un changement significatif du modele objet (frein a son | adoption?). Pourtant ca changerait enormement les possibilites | "dynamiques" de C++.
Je serai surpris si elles passent dans C++0x.
-- Gaby
ld <Laurent.Deniau@gmail.com> writes:
| Est-ce que quelqu'un sait s'il y a une chance que les "open multi-
| methods" proposees par B.S. et al. (a GPCE'07) ont une chance d'etre
| dans C++0x? Pour l'instant je n'y vois aucune allusion et je sais que
| cela demande un changement significatif du modele objet (frein a son
| adoption?). Pourtant ca changerait enormement les possibilites
| "dynamiques" de C++.
| Est-ce que quelqu'un sait s'il y a une chance que les "open multi- | methods" proposees par B.S. et al. (a GPCE'07) ont une chance d'etre | dans C++0x? Pour l'instant je n'y vois aucune allusion et je sais que | cela demande un changement significatif du modele objet (frein a son | adoption?). Pourtant ca changerait enormement les possibilites | "dynamiques" de C++.
Je serai surpris si elles passent dans C++0x.
-- Gaby
Alp Mestan
On 30 mai, 06:28, Gabriel Dos Reis wrote:
ld writes:
| Est-ce que quelqu'un sait s'il y a une chance que les "open multi- | methods" proposees par B.S. et al. (a GPCE'07) ont une chance d'etre | dans C++0x? Pour l'instant je n'y vois aucune allusion et je sais que | cela demande un changement significatif du modele objet (frein a son | adoption?). Pourtant ca changerait enormement les possibilites | "dynamiques" de C++.
Je serai surpris si elles passent dans C++0x.
-- Gaby
Qui plus est, Loki fournit des outils sympas de ce côté là. On peut notamment avoir un système de multiple dispatch à temps constant, en modifiant un chouilla les classes de la hiérarchie qui est impliquée.
On 30 mai, 06:28, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
ld <Laurent.Den...@gmail.com> writes:
| Est-ce que quelqu'un sait s'il y a une chance que les "open multi-
| methods" proposees par B.S. et al. (a GPCE'07) ont une chance d'etre
| dans C++0x? Pour l'instant je n'y vois aucune allusion et je sais que
| cela demande un changement significatif du modele objet (frein a son
| adoption?). Pourtant ca changerait enormement les possibilites
| "dynamiques" de C++.
Je serai surpris si elles passent dans C++0x.
-- Gaby
Qui plus est, Loki fournit des outils sympas de ce côté là. On peut
notamment avoir un système de multiple dispatch à temps constant, en
modifiant un chouilla les classes de la hiérarchie qui est impliquée.
| Est-ce que quelqu'un sait s'il y a une chance que les "open multi- | methods" proposees par B.S. et al. (a GPCE'07) ont une chance d'etre | dans C++0x? Pour l'instant je n'y vois aucune allusion et je sais que | cela demande un changement significatif du modele objet (frein a son | adoption?). Pourtant ca changerait enormement les possibilites | "dynamiques" de C++.
Je serai surpris si elles passent dans C++0x.
-- Gaby
Qui plus est, Loki fournit des outils sympas de ce côté là. On peut notamment avoir un système de multiple dispatch à temps constant, en modifiant un chouilla les classes de la hiérarchie qui est impliquée.
les variants sont purement static (il n'y a pas de "type erasure"),
Non, le type réel de l'objet n'est pas statiquement connu.
Et la type erasure, c'est autre chose, et ça n'a rien à voir avec le multi-dispatch.
ca ne peut donc pas marcher. Il faudrait plutot quelque chose base sur boost any qui lui est dynamique. Mais les tentatives sont tres lourdes, tres lentes et pas vraiment convainquantes.
boost.variant fournit du multi-dispatch qui fonctionne à merveille (ce qui est l'objectif des multi-méthodes). Donc ça marche.
> ce qui revient en fait à > modéliser les objets par des tableaux associatifs de chaînes de > caractères vers des objets qui peuvent eux-mêmes êtres des foncti ons.
le typeid serait plus efficace
Un mot-clé C++ est plus efficace qu'une modélisation. Hum, pas très clair tout ça.
mais de toute facon cela ne convient pas non plus puisque ca ne gerera pas l'heritage.
Les langages dynamiques (PHP, Python, etc) sont basés sur ce principe et fonctionnent très bien. En fait, dans de tels langages, le type statique de chaque variable est le type variable, défini ainsi avec une syntaxe ML :
type variable = Object of object | Function of (variable list -> variable) | Procedure of (variable list -> unit) | Int of int | Float of float | Array of (variable, variable) map | Resource of int ... other native types and type object = (string, variable) map
Les classes, ce ne sont que des méta-objets de référence dans ce type de typage.
Et les solutions basees sur dynamic_cast seront tres lentes.
Le multi-dispatch à base de dynamic_cast c'est on ne peut plus stupide, c'est en O(n). Il faut utiliser de la visitation pour être en O(1).
On 30 mai, 02:12, ld <Laurent.Den...@gmail.com> wrote:
les variants sont purement static (il n'y a pas de "type erasure"),
Non, le type réel de l'objet n'est pas statiquement connu.
Et la type erasure, c'est autre chose, et ça n'a rien à voir avec le
multi-dispatch.
ca
ne peut donc pas marcher. Il faudrait plutot quelque chose base sur
boost any qui lui est dynamique. Mais les tentatives sont tres
lourdes, tres lentes et pas vraiment convainquantes.
boost.variant fournit du multi-dispatch qui fonctionne à merveille (ce
qui est l'objectif des multi-méthodes).
Donc ça marche.
> ce qui revient en fait à
> modéliser les objets par des tableaux associatifs de chaînes de
> caractères vers des objets qui peuvent eux-mêmes êtres des foncti ons.
le typeid serait plus efficace
Un mot-clé C++ est plus efficace qu'une modélisation.
Hum, pas très clair tout ça.
mais de toute facon cela ne convient
pas non plus puisque ca ne gerera pas l'heritage.
Les langages dynamiques (PHP, Python, etc) sont basés sur ce principe
et fonctionnent très bien.
En fait, dans de tels langages, le type statique de chaque variable
est le type variable, défini ainsi avec une syntaxe ML :
type variable = Object of object | Function of (variable list ->
variable) | Procedure of (variable list -> unit)
| Int of int | Float of float | Array of (variable,
variable) map | Resource of int ... other native types
and
type object = (string, variable) map
Les classes, ce ne sont que des méta-objets de référence dans ce type
de typage.
Et les solutions
basees sur dynamic_cast seront tres lentes.
Le multi-dispatch à base de dynamic_cast c'est on ne peut plus
stupide, c'est en O(n).
Il faut utiliser de la visitation pour être en O(1).
les variants sont purement static (il n'y a pas de "type erasure"),
Non, le type réel de l'objet n'est pas statiquement connu.
Et la type erasure, c'est autre chose, et ça n'a rien à voir avec le multi-dispatch.
ca ne peut donc pas marcher. Il faudrait plutot quelque chose base sur boost any qui lui est dynamique. Mais les tentatives sont tres lourdes, tres lentes et pas vraiment convainquantes.
boost.variant fournit du multi-dispatch qui fonctionne à merveille (ce qui est l'objectif des multi-méthodes). Donc ça marche.
> ce qui revient en fait à > modéliser les objets par des tableaux associatifs de chaînes de > caractères vers des objets qui peuvent eux-mêmes êtres des foncti ons.
le typeid serait plus efficace
Un mot-clé C++ est plus efficace qu'une modélisation. Hum, pas très clair tout ça.
mais de toute facon cela ne convient pas non plus puisque ca ne gerera pas l'heritage.
Les langages dynamiques (PHP, Python, etc) sont basés sur ce principe et fonctionnent très bien. En fait, dans de tels langages, le type statique de chaque variable est le type variable, défini ainsi avec une syntaxe ML :
type variable = Object of object | Function of (variable list -> variable) | Procedure of (variable list -> unit) | Int of int | Float of float | Array of (variable, variable) map | Resource of int ... other native types and type object = (string, variable) map
Les classes, ce ne sont que des méta-objets de référence dans ce type de typage.
Et les solutions basees sur dynamic_cast seront tres lentes.
Le multi-dispatch à base de dynamic_cast c'est on ne peut plus stupide, c'est en O(n). Il faut utiliser de la visitation pour être en O(1).
Alp Mestan
On 30 mai, 16:49, Gabriel Dos Reis wrote:
Hmm, as-tu lu le papier en question ?
A vrai dire je ne l'avais que parcouru rapidement. Pour réaliser du multiple-dispatch en C++, c'est possible comme le dit Mathias ou avec le système de Loki (qui, selon lequel on choisit, nécessite toutefois de modifier un poil nos classes).
Bref, je ne penses pas que ce soit le genre de choses qui mériteraient que l'on passe encore un moment à l'intégrer à la norme. Après, je ne suis absolument pas en train de dire que c'est inutile de l'intégrer au langage, loin de là.
PS : on parle bien de ce papier : http://www.open-std.org/jtc1/sc22/wg21/do cs/papers/2003/n1529.html ?
On 30 mai, 16:49, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
Hmm, as-tu lu le papier en question ?
A vrai dire je ne l'avais que parcouru rapidement.
Pour réaliser du multiple-dispatch en C++, c'est possible comme le dit
Mathias ou avec le système de Loki (qui, selon lequel on choisit,
nécessite toutefois de modifier un poil nos classes).
Bref, je ne penses pas que ce soit le genre de choses qui mériteraient
que l'on passe encore un moment à l'intégrer à la norme. Après, je ne
suis absolument pas en train de dire que c'est inutile de l'intégrer
au langage, loin de là.
PS : on parle bien de ce papier : http://www.open-std.org/jtc1/sc22/wg21/do cs/papers/2003/n1529.html
?
A vrai dire je ne l'avais que parcouru rapidement. Pour réaliser du multiple-dispatch en C++, c'est possible comme le dit Mathias ou avec le système de Loki (qui, selon lequel on choisit, nécessite toutefois de modifier un poil nos classes).
Bref, je ne penses pas que ce soit le genre de choses qui mériteraient que l'on passe encore un moment à l'intégrer à la norme. Après, je ne suis absolument pas en train de dire que c'est inutile de l'intégrer au langage, loin de là.
PS : on parle bien de ce papier : http://www.open-std.org/jtc1/sc22/wg21/do cs/papers/2003/n1529.html ?
