Pre-Lillehammer mailing

James Kanze <kanze@none> writes:

| Richard Delorme wrote:
|
| >> Gabriel Dos Reis wrote:
| >> > kanze@gabi-soft.fr writes:
|
| >> > |
| >> > | À vrai dire, je crois que je supprimerais aussi les
| >> > | fonctions inline et les templates autre que exportés.
|
| >> > et tu offrirais un éditeur binaire et un clavier à deux
| >> > touches à la place ?
|
| >> Je comprends pas. Je propose à imposer un niveau
| >> d'abstraction plus élevé que le C++ actuel, où
| >> l'implémentation doit toujours se trouver dans un fichier à
| >> part, et non dans l'en-tête, et tu me parles de l'assembleur.
| >> (J'ai aussi dit que les compilateurs n'étaient pas assez
| >> mûrs, parce qu'il y a bien des fois où l'inline est
| >> nécessaire, pour des raisons de performance, parce que les
| >> compilateurs courants ne savent pas le faire automatiquement
| >> quand il le faut.)
|
| > Une fois que l'en-tête ne contient plus de code, on peut aussi
| > le supprimer, non ? Avec quelques autres modifications, on
| > obtient Java...
|
| Par code, j'entendais du code exécutable. Des détails de
| l'implémentation, quoi. Je le considère essentiel que la
| définition de la classe, ou au moins la partie « publique » dont
| se sert le code client, soi dans un fichier séparé du fichier
| (ou des fichiers) qui contient les détails de l'implémentation.
|
| Je me suis exprimé plus d'une fois sur cet aspect de Java, que

... ainsi que beaucoup de gens.
Et pour en revenir aux suppressions, je ne vois toujours pas le
rapport entre ces suppressions et l'allégation que cela élèverait le
niveau d'abstraction.

| je considère comme un défaut assez grave, au moins si on compte
| implémenter de grands projets (avec plusieurs dizaines de
| développeurs).
|
| --
| James Kanze mailto: james.kanze@free.fr
| Conseils en informatique orientée objet/
| Beratung in objektorientierter Datenverarbeitung
| 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

--
Gabriel Dos Reis
gdr@integrable-solutions.net

James Kanze <kanze@none> writes:

| Gabriel Dos Reis wrote:
| > James Kanze <kanze@none> writes:
|
| > | Gabriel Dos Reis wrote:
| > | > kanze@gabi-soft.fr writes:
|
| > | > | À vrai dire, je crois que je supprimerais aussi les
| > | > | fonctions inline et les templates autre que exportés.
|
| > | > et tu offrirais un éditeur binaire et un clavier à deux
| > | > touches à la place ?
|
| > | Je comprends pas. Je propose à imposer un niveau
| > | d'abstraction plus élevé que le C++ actuel, où
| > | l'implémentation doit toujours se trouver dans un fichier à
| > | part, et non dans l'en-tête, et tu me parles de
| > | l'assembleur. (J'ai aussi dit que les compilateurs n'étaient
| > | pas assez mûrs, parce qu'il y a bien des fois où l'inline
| > | est nécessaire, pour des raisons de performance, parce que
| > | les compilateurs courants ne savent pas le faire
| > | automatiquement quand il le faut.)
|
| > Je reformule la question de manière directe : en quoi ces
| > suppressions imposent un niveau d'abstraction plus élévée ?
|
| Elles réduisent le couplage entre ce que voit le code client et
| l'implémentation.

Ah mais ce n'est pas la même chose.
Si tu supprimes les templates non-exportés, le résultat est que soit
on revient à utiliser des macros, soit on exporte des templates
d'implémentation ; je vois difficilement comment cela est une
élevation du niveau d'abstraction.

| D'un certain point de vu, évidemment, on n'a pas besoin des
| suppressions, parce qu'on n'est pas obligé à se servir de ces
| fonctionnalités pour commencer.

Oh didiou.

| (Seulement, évidemment, dans le
| cas des templates non-exportés, il faut bien se servir d'un
| compilateur qui supporte export, ce qui n'est pas le cas de tout
| le monde.) Mais si on ne doit pas s'en servir, pourquoi est-ce
| qu'il faut les supporter.

C'est de la myopie intellectuelle : ce ne sont pas tous les templates
qui doivent exportés, de la même manière que ce sont pas toutes les
fonctions qui font partie de l'interface publique d'une unité de
traduction ou module. Voir plus haut.

| Mais comme d'habitude, tu as choisi aussi de prendre une phrase
| hors contexte. J'avais bien dit par la suite que dans la
| pratique, on ne pouvait pas se passer de ces fonctionalités
| aujourd'hui, à cause des faiblesses des compilateurs actuels.

Je suis content de te retrouver inchangé.

-- Gaby

James Kanze wrote:

Richard Delorme wrote:

Je comprends pas. Je propose à imposer un niveau
d'abstraction plus élevé que le C++ actuel, où
l'implémentation doit toujours se trouver dans un fichier à
part, et non dans l'en-tête, et tu me parles de l'assembleur.
(J'ai aussi dit que les compilateurs n'étaient pas assez
mûrs, parce qu'il y a bien des fois où l'inline est
nécessaire, pour des raisons de performance, parce que les
compilateurs courants ne savent pas le faire automatiquement
quand il le faut.)

Une fois que l'en-tête ne contient plus de code, on peut aussi
le supprimer, non ? Avec quelques autres modifications, on
obtient Java...

Par code, j'entendais du code exécutable. Des détails de
l'implémentation, quoi. Je le considère essentiel que la
définition de la classe, ou au moins la partie « publique » dont
se sert le code client, soi dans un fichier séparé du fichier
(ou des fichiers) qui contient les détails de l'implémentation.

Mais c'est bien souvent le cas même (surtout ?) en Java !
La partie publique dont se sert le client, c'est en général une
interface, décrite dans un fichier. Cette interface est implémentée par
une classe, décrite dans un autre fichier.
Il n'y a bien que dans un C++ "moderne" où l'on a réduit le rôle des
héritages d'interface que l'absence d'une telle séparation se manifeste.

Je me suis exprimé plus d'une fois sur cet aspect de Java, que
je considère comme un défaut assez grave, au moins si on compte
implémenter de grands projets (avec plusieurs dizaines de
développeurs).

Ce que je trouve grave c'est de considérer que l'on peut faire cohabiter
plusieurs dizaines de développeurs au sein d'un même "projet" -- ou
alors il faut m'expliquer ce que signifie le terme projet dans un tel
contexte.

Gabriel Dos Reis wrote:

James Kanze <kanze@none> writes:
| Et pour revenir au point du départ, ce que j'aurais voulu
| supprimer du C++, c'était des fonctions inline et
| l'implémentation des templates dans les fichiers en-têtes. Je ne

et comme le langage ne fait pas de distinction entre « fichiers
d'en-êtes » et le reste peux-tu expliquer comment la suppersion de ces
choses élève le niveau d'abstraction ?

Il est vrai qu'il n'y a pas de distinction formelle du point de vue du
langage mais il y a indubitablement une distinction implicite au sein
d'une application entre les fichiers qui apparaissent dans un #include
et les autres.

Ce qui est certain, quelles que soient les motivations pour retirer ou
ajouter telle ou telle chose dans le langage, c'est que plus on peut
simplifier le contenu des fichiers utilisés en #include, plus on gagne
en abstraction (tout en gardant bien évidemment une maitrîse maximale
sur la granularité des unités de compilation : il ne s'agit pas d'être
obligé de mettre toutes les classes dans un seul fichier).

D'ailleurs si, pour ma part, j'avais à supprimer un truc dans le
langage, ça serait le '#include' mais je ne saurais pas par quoi le
remplacer :-p

Gabriel Dos Reis wrote:

James Kanze <kanze@none> writes:
| Et pour revenir au point du départ, ce que j'aurais voulu
| supprimer du C++, c'était des fonctions inline et
| l'implémentation des templates dans les fichiers en-têtes. Je ne

et comme le langage ne fait pas de distinction entre « fichiers
d'en-êtes » et le reste peux-tu expliquer comment la suppersion de ces
choses élève le niveau d'abstraction ?

Il est vrai qu'il n'y a pas de distinction formelle du point de vue du
langage mais il y a indubitablement une distinction implicite au sein
d'une application entre les fichiers qui apparaissent dans un #include
et les autres.

Ce qui est certain, quelles que soient les motivations pour retirer ou
ajouter telle ou telle chose dans le langage, c'est que plus on peut
simplifier le contenu des fichiers utilisés en #include, plus on gagne
en abstraction (tout en gardant bien évidemment une maitrîse maximale
sur la granularité des unités de compilation : il ne s'agit pas d'être
obligé de mettre toutes les classes dans un seul fichier).

D'ailleurs si, pour ma part, j'avais à supprimer un truc dans le
langage, ça serait le '#include' mais je ne saurais pas par quoi le
remplacer :-p

bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla bla
--
Pierre

Olivier Azeau <read.my.name.and.email.to.firstname@lastname.com> writes:

| Gabriel Dos Reis wrote:
| > James Kanze <kanze@none> writes:
| > | Et pour revenir au point du départ, ce que j'aurais voulu
| > | supprimer du C++, c'était des fonctions inline et
| > | l'implémentation des templates dans les fichiers en-têtes. Je ne
| > et comme le langage ne fait pas de distinction entre « fichiers
| > d'en-êtes » et le reste peux-tu expliquer comment la suppersion de ces
| > choses élève le niveau d'abstraction ?
|
| Il est vrai qu'il n'y a pas de distinction formelle du point de vue du
| langage mais il y a indubitablement une distinction implicite au sein
| d'une application entre les fichiers qui apparaissent dans un #include
| et les autres.

Au sein d'une application *donnée* oui. Et c'est très différent.
En fait, c'est pour ça qu'il y a des « coding standards », faits pour
bânir et canoniser des pratiques. Il y a en a pléthore.
Les besoins et les goûts diffèrent d'un point à l'autre.

Bien sûr, tu trouveras qu'il y a des gens qui font la même chose
depuis trente ans et finissent par croire que ce qu'ils font est
universel. Mais par ce cheminement, il y a plusieurs universels.
Si tu n'aimes pas, n'y touche pas.

| Ce qui est certain, quelles que soient les motivations pour retirer ou
| ajouter telle ou telle chose dans le langage, c'est que plus on peut
| simplifier le contenu des fichiers utilisés en #include, plus on gagne
| en abstraction (tout en gardant bien évidemment une maitrîse maximale

Note que James veut retirer des templates non exportés ; ceux là
n'apparaissent pas forcément dans des #includes.
De fait, on peut gagner en abstraction en factorisant dans des
fichiers #inclus par plusieurs unités de traduction.

| sur la granularité des unités de compilation : il ne s'agit pas d'être
| obligé de mettre toutes les classes dans un seul fichier).
|
| D'ailleurs si, pour ma part, j'avais à supprimer un truc dans le
| langage, ça serait le '#include' mais je ne saurais pas par quoi le
| remplacer :-p

ah tu connais ton D&E ;-)

-- Gaby

Olivier Azeau wrote:

James Kanze wrote:

[...]

Mais c'est bien souvent le cas même (surtout ?) en Java ! La
partie publique dont se sert le client, c'est en général une
interface, décrite dans un fichier. Cette interface est
implémentée par une classe, décrite dans un autre fichier.
Il n'y a bien que dans un C++ "moderne" où l'on a réduit le
rôle des héritages d'interface que l'absence d'une telle
séparation se manifeste.

Je me suis exprimé plus d'une fois sur cet aspect de Java,
que je considère comme un défaut assez grave, au moins si on
compte implémenter de grands projets (avec plusieurs dizaines
de développeurs).

Ce que je trouve grave c'est de considérer que l'on peut faire
cohabiter plusieurs dizaines de développeurs au sein d'un même
"projet" -- ou alors il faut m'expliquer ce que signifie le
terme projet dans un tel contexte.

Et comment fais-tu en Java instancier une interface ?

D'après mes expériences avec le Java, les interfaces (au sens du
langage Java) sont quasiment inutilisable ; il faut prèsque
toujours une classe abstraite, ne serait-ce que pour définir le
contrat, et du coup, on perd la possibilité d'héritage multiple.

--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

James Kanze wrote:

Olivier Azeau wrote:

James Kanze wrote:

[...]

Mais c'est bien souvent le cas même (surtout ?) en Java ! La
partie publique dont se sert le client, c'est en général une
interface, décrite dans un fichier. Cette interface est
implémentée par une classe, décrite dans un autre fichier.
Il n'y a bien que dans un C++ "moderne" où l'on a réduit le
rôle des héritages d'interface que l'absence d'une telle
séparation se manifeste.

Je me suis exprimé plus d'une fois sur cet aspect de Java,
que je considère comme un défaut assez grave, au moins si on
compte implémenter de grands projets (avec plusieurs dizaines
de développeurs).

Ce que je trouve grave c'est de considérer que l'on peut faire
cohabiter plusieurs dizaines de développeurs au sein d'un même
"projet" -- ou alors il faut m'expliquer ce que signifie le
terme projet dans un tel contexte.

Et comment fais-tu en Java instancier une interface ?

Avec une interface sur une fabrique ? ;-)

D'après mes expériences avec le Java, les interfaces (au sens du
langage Java) sont quasiment inutilisable ; il faut prèsque
toujours une classe abstraite, ne serait-ce que pour définir le
contrat, et du coup, on perd la possibilité d'héritage multiple.

Pas compris. De quel contrat parles-tu ? Garantir des
pré/post-conditions sur un membre de l'interface ?

Olivier Azeau wrote:

James Kanze wrote:

Olivier Azeau wrote:

James Kanze wrote:

[...]

Mais c'est bien souvent le cas même (surtout ?) en Java !
La partie publique dont se sert le client, c'est en
général une interface, décrite dans un fichier. Cette
interface est implémentée par une classe, décrite dans un
autre fichier. Il n'y a bien que dans un C++ "moderne" où
l'on a réduit le rôle des héritages d'interface que
l'absence d'une telle séparation se manifeste.

Je me suis exprimé plus d'une fois sur cet aspect de
Java, que je considère comme un défaut assez grave, au
moins si on compte implémenter de grands projets (avec
plusieurs dizaines de développeurs).

Ce que je trouve grave c'est de considérer que l'on peut
faire cohabiter plusieurs dizaines de développeurs au sein
d'un même "projet" -- ou alors il faut m'expliquer ce que
signifie le terme projet dans un tel contexte.

Et comment fais-tu en Java instancier une interface ?

Avec une interface sur une fabrique ? ;-)

C'est beaucoup de travail pour quelque chose qui marche de soi
en C++ (et en Ada). Surtout quand on pense à quel point c'est
essentiel dans la gestion des projets d'une taille importante.

D'après mes expériences avec le Java, les interfaces (au sens
du langage Java) sont quasiment inutilisable ; il faut
prèsque toujours une classe abstraite, ne serait-ce que pour
définir le contrat, et du coup, on perd la possibilité
d'héritage multiple.

Pas compris. De quel contrat parles-tu ? Garantir des
pré/post-conditions sur un membre de l'interface ?

Tout à fait. En C++, en général, quand on a besoin d'un contrat
(ce qui est assez courant pour les classes d'entité), les
fonctions publiques ne sont pas virtuelles ; elles vérifient le
contrat, en renvoyant à des fonctions privées virtuelles pour
l'exécution. En Java, déjà, les fonctions privées ne peuvent pas
être virtuelles (or qu'elles représentent environ les deux tiers
de mes fonctions virtuelles ne C++), je suis obligé à me
rabattre sur des fonctions protégées. Et des vérifications,
c'est du code ; c'est donc interdit dans une interface.

Du coup, dans la seule grande application en Java sur laquelle
j'ai travaillé, on se servait des classes abstraites pour des
interfaces critiques.

--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

James Kanze wrote:

Olivier Azeau wrote:

James Kanze wrote:

Et comment fais-tu en Java instancier une interface ?

Avec une interface sur une fabrique ? ;-)

C'est beaucoup de travail pour quelque chose qui marche de soi
en C++ (et en Ada). Surtout quand on pense à quel point c'est
essentiel dans la gestion des projets d'une taille importante.

Là, je ne te suis pas. Pour moi c'est exactement identique qu'en C++.
Peut être bien (et même certainement) que dans les applis auxquelles je
me suis trouvé confronté, on fait du C++ comme on fait du Java mais la
fabrique est un modèle courant pour instancier et c'est même pour ainsi
dire le seul modèle dans le cas d'une famille d'objets "entité"
implémentant la même interface.

D'après mes expériences avec le Java, les interfaces (au sens
du langage Java) sont quasiment inutilisable ; il faut
prèsque toujours une classe abstraite, ne serait-ce que pour
définir le contrat, et du coup, on perd la possibilité
d'héritage multiple.

Pas compris. De quel contrat parles-tu ? Garantir des
pré/post-conditions sur un membre de l'interface ?

Tout à fait. En C++, en général, quand on a besoin d'un contrat
(ce qui est assez courant pour les classes d'entité), les
fonctions publiques ne sont pas virtuelles ; elles vérifient le
contrat, en renvoyant à des fonctions privées virtuelles pour
l'exécution. En Java, déjà, les fonctions privées ne peuvent pas
être virtuelles (or qu'elles représentent environ les deux tiers
de mes fonctions virtuelles ne C++), je suis obligé à me
rabattre sur des fonctions protégées. Et des vérifications,
c'est du code ; c'est donc interdit dans une interface.

Cette technique ne me parait ni plus ni moins qu'une possibilité parmi
d'autres de workaround pour ces contrats non supportés par le langage,
aussi bien en C++ qu'en Java.
En ce qui me concerne, je me contente d'assertions aux endroits où il y
a effectivement besoin d'être sûr qu'un certain état est atteint, ce qui
d'ailleurs me semble souvent plus parlant en termes de code. Par exemple
une postcondition dans le code de l'appelant ou une précondition en tête
de l'implémentation.