On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud" :
J'ai l'impression que Java (et Microsoft Java, alias C#) veulent enfermer le programmeur dans le mode de pensée prévu par l'auteur du langage, et d'une manière générale cherchent à réduire les possibilités.
enfermer le programmeur dans le mode de pensee prevu par l'auteur de la classe 'sealed', pas par l'auteur du langage.
MB
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de
news:ehdrv050d3heibms3k3feba6kkvla214rp@4ax.com...
On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud" <mm@gdzid.com>:
J'ai l'impression que Java (et Microsoft Java, alias C#) veulent
enfermer le programmeur dans le mode de pensée prévu par l'auteur du
langage, et d'une manière générale cherchent à réduire les
possibilités.
enfermer le programmeur dans le mode de pensee prevu par l'auteur de la
classe 'sealed', pas par l'auteur du langage.
On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud" :
J'ai l'impression que Java (et Microsoft Java, alias C#) veulent enfermer le programmeur dans le mode de pensée prévu par l'auteur du langage, et d'une manière générale cherchent à réduire les possibilités.
enfermer le programmeur dans le mode de pensee prevu par l'auteur de la classe 'sealed', pas par l'auteur du langage.
MB
nmartin
Gabriel Dos Reis wrote:
Fabien LE LEZ writes:
| On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud" : | [...] | La philosophie du C++ est opposée : "Fais ce que tu veux, mais prends | tes responsabilités et affronte les conséquences".
Comme std::map<> ou std::set<> ?
Désolé, je n'ai pas pu résister.
-- Gaby
qu'y a t il a comprendre?
nico
Gabriel Dos Reis wrote:
Fabien LE LEZ <gramster@gramster.com> writes:
| On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud" <mm@gdzid.com>:
| [...]
| La philosophie du C++ est opposée : "Fais ce que tu veux, mais prends
| tes responsabilités et affronte les conséquences".
| On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud" : | [...] | La philosophie du C++ est opposée : "Fais ce que tu veux, mais prends | tes responsabilités et affronte les conséquences".
Comme std::map<> ou std::set<> ?
Désolé, je n'ai pas pu résister.
-- Gaby
qu'y a t il a comprendre?
nico
Laurent Deniau
Michel Michaud wrote:
En fait, je vois mal pourquoi on ferait même une documentation disant de ne pas dériver, plutôt que d'indiquer quels sont les problèmes potentiels si on dérive... En un mot, je suis contre les « sealed » et équivalents, qui existent pourtant en C# et Java (et j'imagine ailleurs). J'aimerais bien que quelqu'un réussisse à me convaincre de leur utilité (si c'est possible) autrement qu'en se servant de la possibilité d'optimisation, qui me paraît bien faible dans des langages qui offrent (ou devraient offrir) des possibilités d'optimisation bien supérieures...
Sans parler d'optimisation, il y a la possibilite de gerer les implementations completement privees. Par exemple en C++ on pourrait imaginer un moyen de declarer la partie public seule dans le header et la partie private seule dans l'implementation. Dans ce cas il est tres difficile de deriver d'une telle classe puisque la classe complete n'est pas connue des autres TU (sauf mecanisme a-la-export), ce qui justifierait de la declarer "final".
L'interet est que la partie concernant l'implementation est completement cachee - y compris les membres - une sorte d'extension de l'ADT aux classes. Perso je l'utilise en C (OOC) et ca me plait assez. Ca rend le header plus lisible et ca met une vraie barriere (psychologique dans mon cas ;-) entre l'interface et l'implementation.
a+, ld.
Michel Michaud wrote:
En fait, je vois mal pourquoi on ferait même une documentation disant
de ne pas dériver, plutôt que d'indiquer quels sont les problèmes
potentiels si on dérive... En un mot, je suis contre les « sealed »
et équivalents, qui existent pourtant en C# et Java (et j'imagine
ailleurs). J'aimerais bien que quelqu'un réussisse à me convaincre de
leur utilité (si c'est possible) autrement qu'en se servant de la
possibilité d'optimisation, qui me paraît bien faible dans des
langages qui offrent (ou devraient offrir) des possibilités
d'optimisation bien supérieures...
Sans parler d'optimisation, il y a la possibilite de gerer les
implementations completement privees. Par exemple en C++ on pourrait
imaginer un moyen de declarer la partie public seule dans le header et
la partie private seule dans l'implementation. Dans ce cas il est tres
difficile de deriver d'une telle classe puisque la classe complete n'est
pas connue des autres TU (sauf mecanisme a-la-export), ce qui
justifierait de la declarer "final".
L'interet est que la partie concernant l'implementation est completement
cachee - y compris les membres - une sorte d'extension de l'ADT aux
classes. Perso je l'utilise en C (OOC) et ca me plait assez. Ca rend le
header plus lisible et ca met une vraie barriere (psychologique dans mon
cas ;-) entre l'interface et l'implementation.
En fait, je vois mal pourquoi on ferait même une documentation disant de ne pas dériver, plutôt que d'indiquer quels sont les problèmes potentiels si on dérive... En un mot, je suis contre les « sealed » et équivalents, qui existent pourtant en C# et Java (et j'imagine ailleurs). J'aimerais bien que quelqu'un réussisse à me convaincre de leur utilité (si c'est possible) autrement qu'en se servant de la possibilité d'optimisation, qui me paraît bien faible dans des langages qui offrent (ou devraient offrir) des possibilités d'optimisation bien supérieures...
Sans parler d'optimisation, il y a la possibilite de gerer les implementations completement privees. Par exemple en C++ on pourrait imaginer un moyen de declarer la partie public seule dans le header et la partie private seule dans l'implementation. Dans ce cas il est tres difficile de deriver d'une telle classe puisque la classe complete n'est pas connue des autres TU (sauf mecanisme a-la-export), ce qui justifierait de la declarer "final".
L'interet est que la partie concernant l'implementation est completement cachee - y compris les membres - une sorte d'extension de l'ADT aux classes. Perso je l'utilise en C (OOC) et ca me plait assez. Ca rend le header plus lisible et ca met une vraie barriere (psychologique dans mon cas ;-) entre l'interface et l'implementation.
a+, ld.
Laurent Deniau
nmartin wrote:
Gabriel Dos Reis wrote:
Fabien LE LEZ writes:
| On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud" : | [...] | La philosophie du C++ est opposée : "Fais ce que tu veux, mais prends | tes responsabilités et affronte les conséquences".
Comme std::map<> ou std::set<> ?
Désolé, je n'ai pas pu résister.
-- Gaby
qu'y a t il a comprendre?
Pour comprendre Gaby, il faut parfois le suivre sur plusieurs newsgroups en parallele ;-) En l'occurence lire le thread recent "Altering objects in a std::set" sur comp.std.c++ (Il y donne un lien sur un papier tres interessant).
a+, ld.
nmartin wrote:
Gabriel Dos Reis wrote:
Fabien LE LEZ <gramster@gramster.com> writes:
| On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud" <mm@gdzid.com>:
| [...]
| La philosophie du C++ est opposée : "Fais ce que tu veux, mais prends
| tes responsabilités et affronte les conséquences".
Comme std::map<> ou std::set<> ?
Désolé, je n'ai pas pu résister.
-- Gaby
qu'y a t il a comprendre?
Pour comprendre Gaby, il faut parfois le suivre sur plusieurs newsgroups
en parallele ;-) En l'occurence lire le thread recent "Altering objects
in a std::set" sur comp.std.c++ (Il y donne un lien sur un papier tres
interessant).
| On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud" : | [...] | La philosophie du C++ est opposée : "Fais ce que tu veux, mais prends | tes responsabilités et affronte les conséquences".
Comme std::map<> ou std::set<> ?
Désolé, je n'ai pas pu résister.
-- Gaby
qu'y a t il a comprendre?
Pour comprendre Gaby, il faut parfois le suivre sur plusieurs newsgroups en parallele ;-) En l'occurence lire le thread recent "Altering objects in a std::set" sur comp.std.c++ (Il y donne un lien sur un papier tres interessant).
a+, ld.
Fabien LE LEZ
On Mon, 31 Jan 2005 14:21:52 +0100, Laurent Deniau :
Sans parler d'optimisation, il y a la possibilite de gerer les implementations completement privees. Par exemple en C++ on pourrait imaginer un moyen de declarer la partie public seule dans le header et la partie private seule dans l'implementation.
On pourrait l'imaginer, effectivement, mais ça n'existe pas[*]. Du coup, je ne vois pas bien comment une fonctionnalité qui n'existe pas devrait imposer la possibilité de déclarer une classe indérivable.
[*] du moins pas directement -- on peut utiliser l'idiome "compilation firewall" (pimpl).
-- ;-)
On Mon, 31 Jan 2005 14:21:52 +0100, Laurent Deniau
<Laurent.Deniau@cern.ch>:
Sans parler d'optimisation, il y a la possibilite de gerer les
implementations completement privees. Par exemple en C++ on pourrait
imaginer un moyen de declarer la partie public seule dans le header et
la partie private seule dans l'implementation.
On pourrait l'imaginer, effectivement, mais ça n'existe pas[*]. Du
coup, je ne vois pas bien comment une fonctionnalité qui n'existe pas
devrait imposer la possibilité de déclarer une classe indérivable.
[*] du moins pas directement -- on peut utiliser l'idiome "compilation
firewall" (pimpl).
On Mon, 31 Jan 2005 14:21:52 +0100, Laurent Deniau :
Sans parler d'optimisation, il y a la possibilite de gerer les implementations completement privees. Par exemple en C++ on pourrait imaginer un moyen de declarer la partie public seule dans le header et la partie private seule dans l'implementation.
On pourrait l'imaginer, effectivement, mais ça n'existe pas[*]. Du coup, je ne vois pas bien comment une fonctionnalité qui n'existe pas devrait imposer la possibilité de déclarer une classe indérivable.
[*] du moins pas directement -- on peut utiliser l'idiome "compilation firewall" (pimpl).
-- ;-)
Laurent Deniau
Fabien LE LEZ wrote:
On Mon, 31 Jan 2005 14:21:52 +0100, Laurent Deniau :
Sans parler d'optimisation, il y a la possibilite de gerer les implementations completement privees. Par exemple en C++ on pourrait imaginer un moyen de declarer la partie public seule dans le header et la partie private seule dans l'implementation.
On pourrait l'imaginer, effectivement, mais ça n'existe pas[*]. Du coup, je ne vois pas bien comment une fonctionnalité qui n'existe pas devrait imposer la possibilité de déclarer une classe indérivable.
Pour citer la question de depart:
<J'aimerais bien que quelqu'un réussisse à me convaincre de leur utilité (si c'est possible) autrement qu'en se servant de la possibilité d'optimisation, qui me paraît bien faible dans des langages qui offrent (ou devraient offrir) des possibilités d'optimisation bien supérieures...>
La question etant ouverte a d'autres languages. Je donnais comme exemple un cas ou ca existe, ou c'est utile et qui ne concerne pas l'optimisation - reduction du couplable, separation totale interface-implementation.
[*] du moins pas directement -- on peut utiliser l'idiome "compilation firewall" (pimpl).
C'est un autre sujet, qui a ses avantages et ses inconvenients. Lakos en parle effectivement dans son livre et il donne egalement les couts en terme de performance.
a+, ld.
Fabien LE LEZ wrote:
On Mon, 31 Jan 2005 14:21:52 +0100, Laurent Deniau
<Laurent.Deniau@cern.ch>:
Sans parler d'optimisation, il y a la possibilite de gerer les
implementations completement privees. Par exemple en C++ on pourrait
imaginer un moyen de declarer la partie public seule dans le header et
la partie private seule dans l'implementation.
On pourrait l'imaginer, effectivement, mais ça n'existe pas[*]. Du
coup, je ne vois pas bien comment une fonctionnalité qui n'existe pas
devrait imposer la possibilité de déclarer une classe indérivable.
Pour citer la question de depart:
<J'aimerais bien que quelqu'un réussisse à me convaincre de
leur utilité (si c'est possible) autrement qu'en se servant de la
possibilité d'optimisation, qui me paraît bien faible dans des
langages qui offrent (ou devraient offrir) des possibilités
d'optimisation bien supérieures...>
La question etant ouverte a d'autres languages. Je donnais comme exemple
un cas ou ca existe, ou c'est utile et qui ne concerne pas
l'optimisation - reduction du couplable, separation totale
interface-implementation.
[*] du moins pas directement -- on peut utiliser l'idiome "compilation
firewall" (pimpl).
C'est un autre sujet, qui a ses avantages et ses inconvenients. Lakos en
parle effectivement dans son livre et il donne egalement les couts en
terme de performance.
On Mon, 31 Jan 2005 14:21:52 +0100, Laurent Deniau :
Sans parler d'optimisation, il y a la possibilite de gerer les implementations completement privees. Par exemple en C++ on pourrait imaginer un moyen de declarer la partie public seule dans le header et la partie private seule dans l'implementation.
On pourrait l'imaginer, effectivement, mais ça n'existe pas[*]. Du coup, je ne vois pas bien comment une fonctionnalité qui n'existe pas devrait imposer la possibilité de déclarer une classe indérivable.
Pour citer la question de depart:
<J'aimerais bien que quelqu'un réussisse à me convaincre de leur utilité (si c'est possible) autrement qu'en se servant de la possibilité d'optimisation, qui me paraît bien faible dans des langages qui offrent (ou devraient offrir) des possibilités d'optimisation bien supérieures...>
La question etant ouverte a d'autres languages. Je donnais comme exemple un cas ou ca existe, ou c'est utile et qui ne concerne pas l'optimisation - reduction du couplable, separation totale interface-implementation.
[*] du moins pas directement -- on peut utiliser l'idiome "compilation firewall" (pimpl).
C'est un autre sujet, qui a ses avantages et ses inconvenients. Lakos en parle effectivement dans son livre et il donne egalement les couts en terme de performance.
a+, ld.
Fabien LE LEZ
On Mon, 31 Jan 2005 14:21:52 +0100, Laurent Deniau :
Dans ce cas il est tres difficile de deriver d'une telle classe puisque la classe complete n'est pas connue des autres TU (sauf mecanisme a-la-export)
Cela ne rejoint-il pas le problème de l'instanciation (i.e. pour instancier un objet, il faut en connaître la taille, et pour connaître la taille, il faut connaître la liste des objets membres ?)
-- ;-)
On Mon, 31 Jan 2005 14:21:52 +0100, Laurent Deniau
<Laurent.Deniau@cern.ch>:
Dans ce cas il est tres
difficile de deriver d'une telle classe puisque la classe complete n'est
pas connue des autres TU (sauf mecanisme a-la-export)
Cela ne rejoint-il pas le problème de l'instanciation (i.e. pour
instancier un objet, il faut en connaître la taille, et pour connaître
la taille, il faut connaître la liste des objets membres ?)
On Mon, 31 Jan 2005 14:21:52 +0100, Laurent Deniau :
Dans ce cas il est tres difficile de deriver d'une telle classe puisque la classe complete n'est pas connue des autres TU (sauf mecanisme a-la-export)
Cela ne rejoint-il pas le problème de l'instanciation (i.e. pour instancier un objet, il faut en connaître la taille, et pour connaître la taille, il faut connaître la liste des objets membres ?)
-- ;-)
Laurent Deniau
Fabien LE LEZ wrote:
On Mon, 31 Jan 2005 14:21:52 +0100, Laurent Deniau :
Dans ce cas il est tres difficile de deriver d'une telle classe puisque la classe complete n'est pas connue des autres TU (sauf mecanisme a-la-export)
Cela ne rejoint-il pas le problème de l'instanciation (i.e. pour instancier un objet, il faut en connaître la taille, et pour connaître la taille, il faut connaître la liste des objets membres ?)
Connaitre la taille de l'objet n'est pas necessairement un gros probleme meme quand les membres ne sont pas connus de l'interface. On peut par exemple penser a ajouter une methode size() a type_info.
size_t objSize = typeid(MyClass).size();
a+, ld.
Fabien LE LEZ wrote:
On Mon, 31 Jan 2005 14:21:52 +0100, Laurent Deniau
<Laurent.Deniau@cern.ch>:
Dans ce cas il est tres
difficile de deriver d'une telle classe puisque la classe complete n'est
pas connue des autres TU (sauf mecanisme a-la-export)
Cela ne rejoint-il pas le problème de l'instanciation (i.e. pour
instancier un objet, il faut en connaître la taille, et pour connaître
la taille, il faut connaître la liste des objets membres ?)
Connaitre la taille de l'objet n'est pas necessairement un gros probleme
meme quand les membres ne sont pas connus de l'interface. On peut par
exemple penser a ajouter une methode size() a type_info.
On Mon, 31 Jan 2005 14:21:52 +0100, Laurent Deniau :
Dans ce cas il est tres difficile de deriver d'une telle classe puisque la classe complete n'est pas connue des autres TU (sauf mecanisme a-la-export)
Cela ne rejoint-il pas le problème de l'instanciation (i.e. pour instancier un objet, il faut en connaître la taille, et pour connaître la taille, il faut connaître la liste des objets membres ?)
Connaitre la taille de l'objet n'est pas necessairement un gros probleme meme quand les membres ne sont pas connus de l'interface. On peut par exemple penser a ajouter une methode size() a type_info.
size_t objSize = typeid(MyClass).size();
a+, ld.
Gabriel Dos Reis
nmartin writes:
| Gabriel Dos Reis wrote: | > Fabien LE LEZ writes: | > | On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud" | > : | > | [...] | > | La philosophie du C++ est opposée : "Fais ce que tu veux, mais prends | > | tes responsabilités et affronte les conséquences". | > Comme std::map<> ou std::set<> ? | > Désolé, je n'ai pas pu résister. | > -- Gaby | | qu'y a t il a comprendre?
que la spécification de std::set<> est faite en violation de la « philosophie de C++ » énoncé dans le message auquel je répondais.
Pire « The LWG believes that the standard is inconsistent, but that this is a design problem rather than a strict defect. »
Ahem.
-- Gaby
nmartin <Twxs@ATTFree.fr> writes:
| Gabriel Dos Reis wrote:
| > Fabien LE LEZ <gramster@gramster.com> writes:
| > | On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud"
| > <mm@gdzid.com>:
| > | [...]
| > | La philosophie du C++ est opposée : "Fais ce que tu veux, mais prends
| > | tes responsabilités et affronte les conséquences".
| > Comme std::map<> ou std::set<> ?
| > Désolé, je n'ai pas pu résister.
| > -- Gaby
|
| qu'y a t il a comprendre?
que la spécification de std::set<> est faite en violation de la
« philosophie de C++ » énoncé dans le message auquel je répondais.
Pire « The LWG believes that the standard is inconsistent, but that
this is a design problem rather than a strict defect. »
| Gabriel Dos Reis wrote: | > Fabien LE LEZ writes: | > | On Sun, 30 Jan 2005 23:13:25 -0500, "Michel Michaud" | > : | > | [...] | > | La philosophie du C++ est opposée : "Fais ce que tu veux, mais prends | > | tes responsabilités et affronte les conséquences". | > Comme std::map<> ou std::set<> ? | > Désolé, je n'ai pas pu résister. | > -- Gaby | | qu'y a t il a comprendre?
que la spécification de std::set<> est faite en violation de la « philosophie de C++ » énoncé dans le message auquel je répondais.
Pire « The LWG believes that the standard is inconsistent, but that this is a design problem rather than a strict defect. »
Ahem.
-- Gaby
Michel Michaud
Dans le message 41fdeb18$0$26227$,
"Michel Michaud" a écrit dans le message de news:KfiLd.1880$
En un mot, je suis contre les « sealed » et équivalents, qui existent pourtant en C# et Java (et j'imagine ailleurs). J'aimerais bien que quelqu'un réussisse à me convaincre de leur utilité (si c'est possible)
On peut développer une classe par exemple gérant la sécurité du système. On a pas envie que l'utilisateur rédéfinisse par exemple la classe de gestion du login...
Ce dont on a envie ou pas ne devrait pas limiter ce que les autres peuvent faire. On peut indiquer dans la documentation pourquoi il vaut mieux ne pas dériver, mais je ne crois pas que « sealed » (ou équivalent) soit une façon de gérer la sécurité d'un système !
(en un mot, ton exemple n'est pas « réaliste »)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message 41fdeb18$0$26227$626a14ce@news.free.fr,
"Michel Michaud" <mm@gdzid.com> a écrit dans le message de
news:KfiLd.1880$Ck1.411930@news20.bellglobal.com...
En un mot, je suis contre les « sealed »
et équivalents, qui existent pourtant en C# et Java (et j'imagine
ailleurs). J'aimerais bien que quelqu'un réussisse à me convaincre
de leur utilité (si c'est possible)
On peut développer une classe par exemple gérant la sécurité du
système. On a pas envie que l'utilisateur rédéfinisse par exemple
la classe de gestion du login...
Ce dont on a envie ou pas ne devrait pas limiter ce que les autres
peuvent faire. On peut indiquer dans la documentation pourquoi il
vaut mieux ne pas dériver, mais je ne crois pas que « sealed » (ou
équivalent) soit une façon de gérer la sécurité d'un système !
(en un mot, ton exemple n'est pas « réaliste »)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
"Michel Michaud" a écrit dans le message de news:KfiLd.1880$
En un mot, je suis contre les « sealed » et équivalents, qui existent pourtant en C# et Java (et j'imagine ailleurs). J'aimerais bien que quelqu'un réussisse à me convaincre de leur utilité (si c'est possible)
On peut développer une classe par exemple gérant la sécurité du système. On a pas envie que l'utilisateur rédéfinisse par exemple la classe de gestion du login...
Ce dont on a envie ou pas ne devrait pas limiter ce que les autres peuvent faire. On peut indiquer dans la documentation pourquoi il vaut mieux ne pas dériver, mais je ne crois pas que « sealed » (ou équivalent) soit une façon de gérer la sécurité d'un système !
(en un mot, ton exemple n'est pas « réaliste »)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
