Bonjour à tous,
On m'a appris en c++ il faut tjrs mettre en ouevre la forme canonique
(construcetur de copie, affectation et je crois je ne suis pas sure
constructeur par defaut)bref.
supposons qu'on a les classes suivante:
class base{
base(const base& right)
{
donnéeComune1 = right.donnéeComune1;
}
};
class derivéA : base{
derivéA (const derivéA & right): base (right)
{
donéeSpécifiqueA = right.donéeSpécifiqueA;
}
};
class derivéB : base{
derivéB (const derivéB & right): base (right)
{
donéeSpécifiqueB = right.donéeSpécifiqueB;
}
};
est ce que c'est bien de mettre un constructeur de copie dans la
classe de base ou non. et qu'est ce qui ce passe si on fait :
Base pBase;
derivéA ptrA(pBase);
derivéA ptrA;
derivéB ptrB(ptrA);
même question pour l'opérateur d'affectation.
merci d'avance.
Par exemple un objet Client, qui aurait donc une identité spécifique, n'a pas de sémantique de valeur (sauf erreur de design). D'une manière générale, les objets réels ont une identité et seuls les objets conceptuels ont une sémantique de valeur.
Qu'est ce qu'un objet conceptuel ? Je comprends bien, grâce à tes explications, la notion d'objet réel mais pas celle d'objet conceptuel...
Un objet "Rectangle" serait conceptuel ?
Par exemple "cette chaise" est un objet réel, "une chaise" est un objet conceptuel. Un (ou n) rectangle(s) sont conceptuels, mais *ce* rectangle est un objet réel...
Si je comprends bien ça veut dire qu'il n'y a aucune raison d'écrire clientA = clientB puisque qu'il est proprement illogique affecter à un client B les "caractéristiques" d'un autre client ? Et que du coup la déclaration d'un constructeur de copie est une erreur...
Oui
Ceci étant, il m'a semblé comprendre (dans un bouquin d'initiation au C++) qu'un constructeur de copie était toujours implémenté par le compilateur dans le cas ou je n'en fournirais pas un et que dans ce cas la copie se faisait "bit à bit". C'est donc pour ça que tu dis "déclarer privés les constructeurs de copie et d'affectation et à ne pas les définir" ? On redéfini l'opérateur de copie afin que non seulement il ne fasse "rien" mais qu'en plus étant privé il soit totalement inaccessible donc provoquant une erreur de compilation si on tente de l'utiliser ??
Exactement, si ce n'est qu'il est inutile de *définir* l'opérateur de copie ou le constructeur de copie en section private, il suffit de les y déclarer.
Chris
"Zouplaz" <pouet@pouet.com> a écrit dans le message de
news:Xns94077B6F8AC83Zoupla@213.228.0.133...
Par exemple un objet Client, qui aurait donc une identité spécifique,
n'a pas de sémantique de valeur (sauf erreur de design). D'une manière
générale, les objets réels ont une identité et seuls les objets
conceptuels ont une sémantique de valeur.
Qu'est ce qu'un objet conceptuel ? Je comprends bien, grâce à tes
explications, la notion d'objet réel mais pas celle d'objet conceptuel...
Un objet "Rectangle" serait conceptuel ?
Par exemple "cette chaise" est un objet réel, "une chaise" est un objet
conceptuel. Un (ou n) rectangle(s) sont conceptuels, mais *ce* rectangle est
un objet réel...
Si je comprends bien ça veut dire qu'il n'y a aucune raison d'écrire
clientA = clientB puisque qu'il est proprement illogique affecter à un
client B les "caractéristiques" d'un autre client ? Et que du coup la
déclaration d'un constructeur de copie est une erreur...
Oui
Ceci étant, il m'a semblé comprendre (dans un bouquin d'initiation au
C++) qu'un constructeur de copie était toujours implémenté par le
compilateur dans le cas ou je n'en fournirais pas un et que dans ce cas
la copie se faisait "bit à bit". C'est donc pour ça que tu dis "déclarer
privés les constructeurs de copie et d'affectation et à ne pas les
définir" ? On redéfini l'opérateur de copie afin que non seulement il ne
fasse "rien" mais qu'en plus étant privé il soit totalement inaccessible
donc provoquant une erreur de compilation si on tente de l'utiliser ??
Exactement, si ce n'est qu'il est inutile de *définir* l'opérateur de copie
ou le constructeur de copie en section private, il suffit de les y déclarer.
Par exemple un objet Client, qui aurait donc une identité spécifique, n'a pas de sémantique de valeur (sauf erreur de design). D'une manière générale, les objets réels ont une identité et seuls les objets conceptuels ont une sémantique de valeur.
Qu'est ce qu'un objet conceptuel ? Je comprends bien, grâce à tes explications, la notion d'objet réel mais pas celle d'objet conceptuel...
Un objet "Rectangle" serait conceptuel ?
Par exemple "cette chaise" est un objet réel, "une chaise" est un objet conceptuel. Un (ou n) rectangle(s) sont conceptuels, mais *ce* rectangle est un objet réel...
Si je comprends bien ça veut dire qu'il n'y a aucune raison d'écrire clientA = clientB puisque qu'il est proprement illogique affecter à un client B les "caractéristiques" d'un autre client ? Et que du coup la déclaration d'un constructeur de copie est une erreur...
Oui
Ceci étant, il m'a semblé comprendre (dans un bouquin d'initiation au C++) qu'un constructeur de copie était toujours implémenté par le compilateur dans le cas ou je n'en fournirais pas un et que dans ce cas la copie se faisait "bit à bit". C'est donc pour ça que tu dis "déclarer privés les constructeurs de copie et d'affectation et à ne pas les définir" ? On redéfini l'opérateur de copie afin que non seulement il ne fasse "rien" mais qu'en plus étant privé il soit totalement inaccessible donc provoquant une erreur de compilation si on tente de l'utiliser ??
Exactement, si ce n'est qu'il est inutile de *définir* l'opérateur de copie ou le constructeur de copie en section private, il suffit de les y déclarer.
Chris
Christophe Lephay
"Christophe Lephay" a écrit dans le message de news:blepi8$8g8$
"Zouplaz" a écrit dans le message de news:
Qu'est ce qu'un objet conceptuel ? Je comprends bien, grâce à tes explications, la notion d'objet réel mais pas celle d'objet conceptuel...
Un objet "Rectangle" serait conceptuel ?
Par exemple "cette chaise" est un objet réel, "une chaise" est un objet conceptuel. Un (ou n) rectangle(s) sont conceptuels, mais *ce* rectangle est
un objet réel...
Au passage, j'ai choisi le terme "conceptuel" parce qu'il me semblait signifier ce que je voulais dire, et il n'y a donc aucun caractère officiel ou académique...
Chris
"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le message
de news:blepi8$8g8$1@news-reader2.wanadoo.fr...
"Zouplaz" <pouet@pouet.com> a écrit dans le message de
news:Xns94077B6F8AC83Zoupla@213.228.0.133...
Qu'est ce qu'un objet conceptuel ? Je comprends bien, grâce à tes
explications, la notion d'objet réel mais pas celle d'objet
conceptuel...
Un objet "Rectangle" serait conceptuel ?
Par exemple "cette chaise" est un objet réel, "une chaise" est un objet
conceptuel. Un (ou n) rectangle(s) sont conceptuels, mais *ce* rectangle
est
un objet réel...
Au passage, j'ai choisi le terme "conceptuel" parce qu'il me semblait
signifier ce que je voulais dire, et il n'y a donc aucun caractère officiel
ou académique...
"Christophe Lephay" a écrit dans le message de news:blepi8$8g8$
"Zouplaz" a écrit dans le message de news:
Qu'est ce qu'un objet conceptuel ? Je comprends bien, grâce à tes explications, la notion d'objet réel mais pas celle d'objet conceptuel...
Un objet "Rectangle" serait conceptuel ?
Par exemple "cette chaise" est un objet réel, "une chaise" est un objet conceptuel. Un (ou n) rectangle(s) sont conceptuels, mais *ce* rectangle est
un objet réel...
Au passage, j'ai choisi le terme "conceptuel" parce qu'il me semblait signifier ce que je voulais dire, et il n'y a donc aucun caractère officiel ou académique...
Chris
Zouplaz
Christophe Lephay - :
Par exemple "cette chaise" est un objet réel, "une chaise" est un objet conceptuel. Un (ou n) rectangle(s) sont conceptuels, mais *ce* rectangle est
un objet réel...
Au passage, j'ai choisi le terme "conceptuel" parce qu'il me semblait signifier ce que je voulais dire, et il n'y a donc aucun caractère officiel ou académique...
Au fait, je pourrais traduire "une chaise" par classe chaise et "cette chaise" par une instance de chaise... Est-ce juste ?
Si ce n'est pas ça alors est-ce qu'un objet conceptuel (imaginaire, abstrait ?) ne serait qu'une vue de l'esprit ou bien cela se traduirait par quelque chose de précis d'un point de vue c++ ?
Par exemple "cette chaise" est un objet réel, "une chaise" est un
objet conceptuel. Un (ou n) rectangle(s) sont conceptuels, mais *ce*
rectangle
est
un objet réel...
Au passage, j'ai choisi le terme "conceptuel" parce qu'il me semblait
signifier ce que je voulais dire, et il n'y a donc aucun caractère
officiel ou académique...
Au fait, je pourrais traduire "une chaise" par classe chaise et "cette
chaise" par une instance de chaise... Est-ce juste ?
Si ce n'est pas ça alors est-ce qu'un objet conceptuel (imaginaire,
abstrait ?) ne serait qu'une vue de l'esprit ou bien cela se traduirait par
quelque chose de précis d'un point de vue c++ ?
Par exemple "cette chaise" est un objet réel, "une chaise" est un objet conceptuel. Un (ou n) rectangle(s) sont conceptuels, mais *ce* rectangle est
un objet réel...
Au passage, j'ai choisi le terme "conceptuel" parce qu'il me semblait signifier ce que je voulais dire, et il n'y a donc aucun caractère officiel ou académique...
Au fait, je pourrais traduire "une chaise" par classe chaise et "cette chaise" par une instance de chaise... Est-ce juste ?
Si ce n'est pas ça alors est-ce qu'un objet conceptuel (imaginaire, abstrait ?) ne serait qu'une vue de l'esprit ou bien cela se traduirait par quelque chose de précis d'un point de vue c++ ?
Christophe Lephay
"Zouplaz" a écrit dans le message de news:
Au fait, je pourrais traduire "une chaise" par classe chaise et "cette chaise" par une instance de chaise... Est-ce juste ?
Si ce n'est pas ça alors est-ce qu'un objet conceptuel (imaginaire, abstrait ?) ne serait qu'une vue de l'esprit ou bien cela se traduirait par
quelque chose de précis d'un point de vue c++ ?
Ce n'est qu'une vue de l'esprit. La question concerne l'identité. Un objet réel en a une d'une manière général (bien qu'en donner une à sa représentation soit une autre affaire)...
Chris
"Zouplaz" <pouet@pouet.com> a écrit dans le message de
news:Xns9407CC237DCD1Zoupla@213.228.0.138...
Au fait, je pourrais traduire "une chaise" par classe chaise et "cette
chaise" par une instance de chaise... Est-ce juste ?
Si ce n'est pas ça alors est-ce qu'un objet conceptuel (imaginaire,
abstrait ?) ne serait qu'une vue de l'esprit ou bien cela se traduirait
par
quelque chose de précis d'un point de vue c++ ?
Ce n'est qu'une vue de l'esprit. La question concerne l'identité. Un objet
réel en a une d'une manière général (bien qu'en donner une à sa
représentation soit une autre affaire)...
Au fait, je pourrais traduire "une chaise" par classe chaise et "cette chaise" par une instance de chaise... Est-ce juste ?
Si ce n'est pas ça alors est-ce qu'un objet conceptuel (imaginaire, abstrait ?) ne serait qu'une vue de l'esprit ou bien cela se traduirait par
quelque chose de précis d'un point de vue c++ ?
Ce n'est qu'une vue de l'esprit. La question concerne l'identité. Un objet réel en a une d'une manière général (bien qu'en donner une à sa représentation soit une autre affaire)...
Chris
kanze
"Christophe Lephay" wrote in message news:<blepi8$8g8$...
"Zouplaz" a écrit dans le message de news:
Christophe Lephay - :
Par exemple un objet Client, qui aurait donc une identité spécifique, n'a pas de sémantique de valeur (sauf erreur de design). D'une manière générale, les objets réels ont une identité et seuls les objets conceptuels ont une sémantique de valeur.
Qu'est ce qu'un objet conceptuel ? Je comprends bien, grâce à tes explications, la notion d'objet réel mais pas celle d'objet conceptuel...
Un objet "Rectangle" serait conceptuel ?
Par exemple "cette chaise" est un objet réel, "une chaise" est un objet conceptuel. Un (ou n) rectangle(s) sont conceptuels, mais *ce* rectangle est un objet réel...
Point de vue intéressant. Mais comment le traduire en informatique ?
Je suis bien d'accord que si le programme doit traiter « cette chaise », ce n'est pas avec une sémantique de valeur -- l'objet a une identité réele. Mais je vois mal l'autre côté.
En fait, mais c'est une présentation bien plus bas niveau, je dirais qu'un objet a des attributes (pour une chaise, la couleur, par exemple). Or, si ces attributes sont toute la signification de l'objet, et que je peux utiliser n'importe quel objet à sa place, pourvu qu'il a les mêmes attributes, l'objet a une sémantique de valeur.
En revanche, il existe des objets avec un dynamique -- souvent, mais pas forcement, représentée par des attributes d'état dynamique, et une identité. Du coup, si je vais travaillé sur l'objet X, c'est bien l'objet X qu'il me faut, et non un objet quelconque qui aurait par hazard la même valeur.
L'exemple classique, c'est un compte en banque, et de l'argent. Admettons que j'ai la ligne suivante dans mon code :
monCompte->ajoute( centEuros ) ;
monCompte, c'est un pointeur à Compte, et centEuros, c'est une variable de type Montant. Dans ce cas-ci, il est évident que ça m'est complétement égal l'identité de l'objet « centEuros » -- n'importe quel objet de type Montant avec la valeur 100 Euros me ferait l'affaire. En revanche, je tiens beaucoup à ce maCompte pointe réelement à mon compte, et non à une copie temporaire quelconque qui va disparaître plus tard.
On dirait donc que les objets de type Montant ont une sémantique de valeur, et ceux de type Compte ne l'ont pas.
Si je comprends bien ça veut dire qu'il n'y a aucune raison d'écrire clientA = clientB puisque qu'il est proprement illogique affecter à un client B les "caractéristiques" d'un autre client ? Et que du coup la déclaration d'un constructeur de copie est une erreur...
Oui
Ceci étant, il m'a semblé comprendre (dans un bouquin d'initiation au C++) qu'un constructeur de copie était toujours implémenté par le compilateur dans le cas ou je n'en fournirais pas un et que dans ce cas la copie se faisait "bit à bit". C'est donc pour ça que tu dis "déclarer privés les constructeurs de copie et d'affectation et à ne pas les définir" ? On redéfini l'opérateur de copie afin que non seulement il ne fasse "rien" mais qu'en plus étant privé il soit totalement inaccessible donc provoquant une erreur de compilation si on tente de l'utiliser ??
Exactement, si ce n'est qu'il est inutile de *définir* l'opérateur de copie ou le constructeur de copie en section private, il suffit de les y déclarer.
Ça dépend. Dans beaucoup d'applications, des objets de type Compte supporteront quand même la copie ou l'affectation, afin de supporter des transactions avec rollback.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Christophe Lephay" <christophe-lephay@wanadoo.fr> wrote in message
news:<blepi8$8g8$1@news-reader2.wanadoo.fr>...
"Zouplaz" <pouet@pouet.com> a écrit dans le message de
news:Xns94077B6F8AC83Zoupla@213.228.0.133...
Par exemple un objet Client, qui aurait donc une identité
spécifique, n'a pas de sémantique de valeur (sauf erreur de
design). D'une manière générale, les objets réels ont une identité
et seuls les objets conceptuels ont une sémantique de valeur.
Qu'est ce qu'un objet conceptuel ? Je comprends bien, grâce à tes
explications, la notion d'objet réel mais pas celle d'objet
conceptuel...
Un objet "Rectangle" serait conceptuel ?
Par exemple "cette chaise" est un objet réel, "une chaise" est un
objet conceptuel. Un (ou n) rectangle(s) sont conceptuels, mais *ce*
rectangle est un objet réel...
Point de vue intéressant. Mais comment le traduire en informatique ?
Je suis bien d'accord que si le programme doit traiter « cette chaise »,
ce n'est pas avec une sémantique de valeur -- l'objet a une identité
réele. Mais je vois mal l'autre côté.
En fait, mais c'est une présentation bien plus bas niveau, je dirais
qu'un objet a des attributes (pour une chaise, la couleur, par exemple).
Or, si ces attributes sont toute la signification de l'objet, et que je
peux utiliser n'importe quel objet à sa place, pourvu qu'il a les mêmes
attributes, l'objet a une sémantique de valeur.
En revanche, il existe des objets avec un dynamique -- souvent, mais pas
forcement, représentée par des attributes d'état dynamique, et une
identité. Du coup, si je vais travaillé sur l'objet X, c'est bien
l'objet X qu'il me faut, et non un objet quelconque qui aurait par
hazard la même valeur.
L'exemple classique, c'est un compte en banque, et de l'argent.
Admettons que j'ai la ligne suivante dans mon code :
monCompte->ajoute( centEuros ) ;
monCompte, c'est un pointeur à Compte, et centEuros, c'est une variable
de type Montant. Dans ce cas-ci, il est évident que ça m'est
complétement égal l'identité de l'objet « centEuros » -- n'importe quel
objet de type Montant avec la valeur 100 Euros me ferait l'affaire. En
revanche, je tiens beaucoup à ce maCompte pointe réelement à mon compte,
et non à une copie temporaire quelconque qui va disparaître plus tard.
On dirait donc que les objets de type Montant ont une sémantique de
valeur, et ceux de type Compte ne l'ont pas.
Si je comprends bien ça veut dire qu'il n'y a aucune raison d'écrire
clientA = clientB puisque qu'il est proprement illogique affecter à
un client B les "caractéristiques" d'un autre client ? Et que du
coup la déclaration d'un constructeur de copie est une erreur...
Oui
Ceci étant, il m'a semblé comprendre (dans un bouquin d'initiation
au C++) qu'un constructeur de copie était toujours implémenté par le
compilateur dans le cas ou je n'en fournirais pas un et que dans ce
cas la copie se faisait "bit à bit". C'est donc pour ça que tu dis
"déclarer privés les constructeurs de copie et d'affectation et à ne
pas les définir" ? On redéfini l'opérateur de copie afin que non
seulement il ne fasse "rien" mais qu'en plus étant privé il soit
totalement inaccessible donc provoquant une erreur de compilation si
on tente de l'utiliser ??
Exactement, si ce n'est qu'il est inutile de *définir* l'opérateur de
copie ou le constructeur de copie en section private, il suffit de les
y déclarer.
Ça dépend. Dans beaucoup d'applications, des objets de type Compte
supporteront quand même la copie ou l'affectation, afin de supporter des
transactions avec rollback.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Christophe Lephay" wrote in message news:<blepi8$8g8$...
"Zouplaz" a écrit dans le message de news:
Christophe Lephay - :
Par exemple un objet Client, qui aurait donc une identité spécifique, n'a pas de sémantique de valeur (sauf erreur de design). D'une manière générale, les objets réels ont une identité et seuls les objets conceptuels ont une sémantique de valeur.
Qu'est ce qu'un objet conceptuel ? Je comprends bien, grâce à tes explications, la notion d'objet réel mais pas celle d'objet conceptuel...
Un objet "Rectangle" serait conceptuel ?
Par exemple "cette chaise" est un objet réel, "une chaise" est un objet conceptuel. Un (ou n) rectangle(s) sont conceptuels, mais *ce* rectangle est un objet réel...
Point de vue intéressant. Mais comment le traduire en informatique ?
Je suis bien d'accord que si le programme doit traiter « cette chaise », ce n'est pas avec une sémantique de valeur -- l'objet a une identité réele. Mais je vois mal l'autre côté.
En fait, mais c'est une présentation bien plus bas niveau, je dirais qu'un objet a des attributes (pour une chaise, la couleur, par exemple). Or, si ces attributes sont toute la signification de l'objet, et que je peux utiliser n'importe quel objet à sa place, pourvu qu'il a les mêmes attributes, l'objet a une sémantique de valeur.
En revanche, il existe des objets avec un dynamique -- souvent, mais pas forcement, représentée par des attributes d'état dynamique, et une identité. Du coup, si je vais travaillé sur l'objet X, c'est bien l'objet X qu'il me faut, et non un objet quelconque qui aurait par hazard la même valeur.
L'exemple classique, c'est un compte en banque, et de l'argent. Admettons que j'ai la ligne suivante dans mon code :
monCompte->ajoute( centEuros ) ;
monCompte, c'est un pointeur à Compte, et centEuros, c'est une variable de type Montant. Dans ce cas-ci, il est évident que ça m'est complétement égal l'identité de l'objet « centEuros » -- n'importe quel objet de type Montant avec la valeur 100 Euros me ferait l'affaire. En revanche, je tiens beaucoup à ce maCompte pointe réelement à mon compte, et non à une copie temporaire quelconque qui va disparaître plus tard.
On dirait donc que les objets de type Montant ont une sémantique de valeur, et ceux de type Compte ne l'ont pas.
Si je comprends bien ça veut dire qu'il n'y a aucune raison d'écrire clientA = clientB puisque qu'il est proprement illogique affecter à un client B les "caractéristiques" d'un autre client ? Et que du coup la déclaration d'un constructeur de copie est une erreur...
Oui
Ceci étant, il m'a semblé comprendre (dans un bouquin d'initiation au C++) qu'un constructeur de copie était toujours implémenté par le compilateur dans le cas ou je n'en fournirais pas un et que dans ce cas la copie se faisait "bit à bit". C'est donc pour ça que tu dis "déclarer privés les constructeurs de copie et d'affectation et à ne pas les définir" ? On redéfini l'opérateur de copie afin que non seulement il ne fasse "rien" mais qu'en plus étant privé il soit totalement inaccessible donc provoquant une erreur de compilation si on tente de l'utiliser ??
Exactement, si ce n'est qu'il est inutile de *définir* l'opérateur de copie ou le constructeur de copie en section private, il suffit de les y déclarer.
Ça dépend. Dans beaucoup d'applications, des objets de type Compte supporteront quand même la copie ou l'affectation, afin de supporter des transactions avec rollback.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Gabriel Dos Reis
writes:
[...]
| L'exemple classique, c'est un compte en banque, et de l'argent. | Admettons que j'ai la ligne suivante dans mon code : | | monCompte->ajoute( centEuros ) ; | | monCompte, c'est un pointeur à Compte, et centEuros, c'est une variable | de type Montant. Dans ce cas-ci, il est évident que ça m'est | complétement égal l'identité de l'objet « centEuros » -- n'importe quel | objet de type Montant avec la valeur 100 Euros me ferait l'affaire.
Des fois, le fisc n'est pas d'accord avec cette interprétation de valeur (au propre comme au figuré).
-- Gaby
kanze@gabi-soft.fr writes:
[...]
| L'exemple classique, c'est un compte en banque, et de l'argent.
| Admettons que j'ai la ligne suivante dans mon code :
|
| monCompte->ajoute( centEuros ) ;
|
| monCompte, c'est un pointeur à Compte, et centEuros, c'est une variable
| de type Montant. Dans ce cas-ci, il est évident que ça m'est
| complétement égal l'identité de l'objet « centEuros » -- n'importe quel
| objet de type Montant avec la valeur 100 Euros me ferait l'affaire.
Des fois, le fisc n'est pas d'accord avec cette interprétation de
valeur (au propre comme au figuré).
| L'exemple classique, c'est un compte en banque, et de l'argent. | Admettons que j'ai la ligne suivante dans mon code : | | monCompte->ajoute( centEuros ) ; | | monCompte, c'est un pointeur à Compte, et centEuros, c'est une variable | de type Montant. Dans ce cas-ci, il est évident que ça m'est | complétement égal l'identité de l'objet « centEuros » -- n'importe quel | objet de type Montant avec la valeur 100 Euros me ferait l'affaire.
Des fois, le fisc n'est pas d'accord avec cette interprétation de valeur (au propre comme au figuré).
-- Gaby
Christophe Lephay
a écrit dans le message de news:
"Christophe Lephay" wrote in message news:<blepi8$8g8$...
Par exemple "cette chaise" est un objet réel, "une chaise" est un objet conceptuel. Un (ou n) rectangle(s) sont conceptuels, mais *ce* rectangle est un objet réel...
Point de vue intéressant. Mais comment le traduire en informatique ? Je suis bien d'accord que si le programme doit traiter « cette chaise », ce n'est pas avec une sémantique de valeur -- l'objet a une identité réele. Mais je vois mal l'autre côté.
Voir plus bas...
En fait, mais c'est une présentation bien plus bas niveau, je dirais qu'un objet a des attributes (pour une chaise, la couleur, par exemple). Or, si ces attributes sont toute la signification de l'objet, et que je peux utiliser n'importe quel objet à sa place, pourvu qu'il a les mêmes attributes, l'objet a une sémantique de valeur.
Celà me parait clair (après l'avoir lu plusieurs fois quand même lol)...
D'une certaine manière, dans un cas c'est l'objet lui-même qui compte alors que dans l'autre, ce sont plus ses propriétés...
Par exemple, pour un antiquaire, c'est l'objet lui-même qui compte en tant que quelque chose d'unique alors que pour un déménageur, ce sont son poids ou ses dimensions qui ont une signification.
C'est vraiment pas évident de dégager une "règle canonique" de quand utiliser une sémantique de valeur et de quand ne pas le faire. Dire que c'est quand le type doit supporter l'affectation est clair et concis, mais ne dit rien sur *quand* un type doit supporter l'affectation :)
Chris
<kanze@gabi-soft.fr> a écrit dans le message de
news:d6652001.0310020019.52a84772@posting.google.com...
"Christophe Lephay" <christophe-lephay@wanadoo.fr> wrote in message
news:<blepi8$8g8$1@news-reader2.wanadoo.fr>...
Par exemple "cette chaise" est un objet réel, "une chaise" est un
objet conceptuel. Un (ou n) rectangle(s) sont conceptuels, mais *ce*
rectangle est un objet réel...
Point de vue intéressant. Mais comment le traduire en informatique ?
Je suis bien d'accord que si le programme doit traiter « cette chaise »,
ce n'est pas avec une sémantique de valeur -- l'objet a une identité
réele. Mais je vois mal l'autre côté.
Voir plus bas...
En fait, mais c'est une présentation bien plus bas niveau, je dirais
qu'un objet a des attributes (pour une chaise, la couleur, par exemple).
Or, si ces attributes sont toute la signification de l'objet, et que je
peux utiliser n'importe quel objet à sa place, pourvu qu'il a les mêmes
attributes, l'objet a une sémantique de valeur.
Celà me parait clair (après l'avoir lu plusieurs fois quand même lol)...
D'une certaine manière, dans un cas c'est l'objet lui-même qui compte alors
que dans l'autre, ce sont plus ses propriétés...
Par exemple, pour un antiquaire, c'est l'objet lui-même qui compte en tant
que quelque chose d'unique alors que pour un déménageur, ce sont son poids
ou ses dimensions qui ont une signification.
C'est vraiment pas évident de dégager une "règle canonique" de quand
utiliser une sémantique de valeur et de quand ne pas le faire. Dire que
c'est quand le type doit supporter l'affectation est clair et concis, mais
ne dit rien sur *quand* un type doit supporter l'affectation :)
"Christophe Lephay" wrote in message news:<blepi8$8g8$...
Par exemple "cette chaise" est un objet réel, "une chaise" est un objet conceptuel. Un (ou n) rectangle(s) sont conceptuels, mais *ce* rectangle est un objet réel...
Point de vue intéressant. Mais comment le traduire en informatique ? Je suis bien d'accord que si le programme doit traiter « cette chaise », ce n'est pas avec une sémantique de valeur -- l'objet a une identité réele. Mais je vois mal l'autre côté.
Voir plus bas...
En fait, mais c'est une présentation bien plus bas niveau, je dirais qu'un objet a des attributes (pour une chaise, la couleur, par exemple). Or, si ces attributes sont toute la signification de l'objet, et que je peux utiliser n'importe quel objet à sa place, pourvu qu'il a les mêmes attributes, l'objet a une sémantique de valeur.
Celà me parait clair (après l'avoir lu plusieurs fois quand même lol)...
D'une certaine manière, dans un cas c'est l'objet lui-même qui compte alors que dans l'autre, ce sont plus ses propriétés...
Par exemple, pour un antiquaire, c'est l'objet lui-même qui compte en tant que quelque chose d'unique alors que pour un déménageur, ce sont son poids ou ses dimensions qui ont une signification.
C'est vraiment pas évident de dégager une "règle canonique" de quand utiliser une sémantique de valeur et de quand ne pas le faire. Dire que c'est quand le type doit supporter l'affectation est clair et concis, mais ne dit rien sur *quand* un type doit supporter l'affectation :)
Chris
Gabriel Dos Reis
"Christophe Lephay" writes:
| C'est vraiment pas évident de dégager une "règle canonique" de quand | utiliser une sémantique de valeur et de quand ne pas le faire. Dire que | c'est quand le type doit supporter l'affectation est clair et concis, mais | ne dit rien sur *quand* un type doit supporter l'affectation :)
tu ne voudrais quand même pas que la vie se réduise à de simples applications mécaniques de règles formelles ;-)
| C'est vraiment pas évident de dégager une "règle canonique" de quand
| utiliser une sémantique de valeur et de quand ne pas le faire. Dire que
| c'est quand le type doit supporter l'affectation est clair et concis, mais
| ne dit rien sur *quand* un type doit supporter l'affectation :)
tu ne voudrais quand même pas que la vie se réduise à de simples
applications mécaniques de règles formelles ;-)
| C'est vraiment pas évident de dégager une "règle canonique" de quand | utiliser une sémantique de valeur et de quand ne pas le faire. Dire que | c'est quand le type doit supporter l'affectation est clair et concis, mais | ne dit rien sur *quand* un type doit supporter l'affectation :)
tu ne voudrais quand même pas que la vie se réduise à de simples applications mécaniques de règles formelles ;-)
-- Gaby
Christophe Lephay
"Gabriel Dos Reis" a écrit dans le message de news:
"Christophe Lephay" writes:
| C'est vraiment pas évident de dégager une "règle canonique" de quand | utiliser une sémantique de valeur et de quand ne pas le faire. Dire que | c'est quand le type doit supporter l'affectation est clair et concis, mais
| ne dit rien sur *quand* un type doit supporter l'affectation :)
tu ne voudrais quand même pas que la vie se réduise à de simples applications mécaniques de règles formelles ;-)
Pas jusque là, non :)
Néanmoins, il y a pas mal de processus cognitifs qu'on arrive à "formuler" (il y en a encore plus pour lesquels on n'y arrive pas, mais bon)...
Chris
"Gabriel Dos Reis" <dosreis@cmla.ens-cachan.fr> a écrit dans le message de
news:flvfr7zqpz.fsf@sel.cmla.ens-cachan.fr...
| C'est vraiment pas évident de dégager une "règle canonique" de quand
| utiliser une sémantique de valeur et de quand ne pas le faire. Dire que
| c'est quand le type doit supporter l'affectation est clair et concis,
mais
| ne dit rien sur *quand* un type doit supporter l'affectation :)
tu ne voudrais quand même pas que la vie se réduise à de simples
applications mécaniques de règles formelles ;-)
Pas jusque là, non :)
Néanmoins, il y a pas mal de processus cognitifs qu'on arrive à "formuler"
(il y en a encore plus pour lesquels on n'y arrive pas, mais bon)...
"Gabriel Dos Reis" a écrit dans le message de news:
"Christophe Lephay" writes:
| C'est vraiment pas évident de dégager une "règle canonique" de quand | utiliser une sémantique de valeur et de quand ne pas le faire. Dire que | c'est quand le type doit supporter l'affectation est clair et concis, mais
| ne dit rien sur *quand* un type doit supporter l'affectation :)
tu ne voudrais quand même pas que la vie se réduise à de simples applications mécaniques de règles formelles ;-)
Pas jusque là, non :)
Néanmoins, il y a pas mal de processus cognitifs qu'on arrive à "formuler" (il y en a encore plus pour lesquels on n'y arrive pas, mais bon)...
Chris
Gabriel Dos Reis
"Christophe Lephay" writes:
[...]
| Néanmoins, il y a pas mal de processus cognitifs qu'on arrive à "formuler" | (il y en a encore plus pour lesquels on n'y arrive pas, mais bon)...
plus précisément, des gens avancent des modèles... mais juste des modèles (c'est bien ainsi, si tu veux mon avis).
