JKB a écrit :Le Wed, 22 Jun 2011 05:47:49 -0700 (PDT),
Aeris Imirhil écrivait :On 22 juin, 13:09, JKB wrote:Ton exemple est typiquement du goret-codage. D'une part, si tu ne
sais pas quel est la prototype de la fonction, tu ferais bien de ne
pas l'utiliser.
Il ne s'agit pas de connaître uniquement le prototype de la fonction
mais la signification exacte de sa valeur de retour : est-ce une
donnée de retour ou un code d'erreur ?
Ça, mon grand, c'est spécifié dans le prototype et l'interface.
tien justement en parlent de truc a la con
voila se que je trouve dans uboot
void __show_boot_progress (int val)
{
return;
}
void show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
je devrait plutot dire
void inline __show_boot_progress (int val)
{
return;
}
void inline show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
qui ne passe pas le compilateur
en gros l'on "surcharge "la fonction show_boot_progress
au lieux de faire le ménage dans le code cool non
JKB a écrit :
Le Wed, 22 Jun 2011 05:47:49 -0700 (PDT),
Aeris Imirhil <aeris.imirhil@gmail.com> écrivait :
On 22 juin, 13:09, JKB <j...@koenigsberg.invalid> wrote:
Ton exemple est typiquement du goret-codage. D'une part, si tu ne
sais pas quel est la prototype de la fonction, tu ferais bien de ne
pas l'utiliser.
Il ne s'agit pas de connaître uniquement le prototype de la fonction
mais la signification exacte de sa valeur de retour : est-ce une
donnée de retour ou un code d'erreur ?
Ça, mon grand, c'est spécifié dans le prototype et l'interface.
tien justement en parlent de truc a la con
voila se que je trouve dans uboot
void __show_boot_progress (int val)
{
return;
}
void show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
je devrait plutot dire
void inline __show_boot_progress (int val)
{
return;
}
void inline show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
qui ne passe pas le compilateur
en gros l'on "surcharge "la fonction show_boot_progress
au lieux de faire le ménage dans le code cool non
JKB a écrit :Le Wed, 22 Jun 2011 05:47:49 -0700 (PDT),
Aeris Imirhil écrivait :On 22 juin, 13:09, JKB wrote:Ton exemple est typiquement du goret-codage. D'une part, si tu ne
sais pas quel est la prototype de la fonction, tu ferais bien de ne
pas l'utiliser.
Il ne s'agit pas de connaître uniquement le prototype de la fonction
mais la signification exacte de sa valeur de retour : est-ce une
donnée de retour ou un code d'erreur ?
Ça, mon grand, c'est spécifié dans le prototype et l'interface.
tien justement en parlent de truc a la con
voila se que je trouve dans uboot
void __show_boot_progress (int val)
{
return;
}
void show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
je devrait plutot dire
void inline __show_boot_progress (int val)
{
return;
}
void inline show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
qui ne passe pas le compilateur
en gros l'on "surcharge "la fonction show_boot_progress
au lieux de faire le ménage dans le code cool non
Michel Talon, dans le message
<itt792$oeb$, a écrit :
> Dans le même ordre d'idée il y a le typage
> automatique et
> dynamique des variables, comme en python, et qui n'existe pas en
> Java,
Là, je ne suis franchement pas d'accord du tout, pour la combinaison
de ces deux raisons :
- Dans un programme correctement écrit et débuggé, une variable n'a
qu'un seul type : si quelque part on écrit « a = x + 42 », c'est que
a et x sont des nombres (entiers ou flottants), et si ailleurs on
utilise a ou x comme des pointeurs ou des tableaux, c'est qu'il y a
un bug.
- Quand il y a un bug, il vaut mieux le détecter le plus tôt
possible, si possible au moment où le programme est compilé ou chargé
plutôt qu'au moment où l'endroit où se trouve l'erreur est exécuté.
Le typage statique des variables permet justement ça, et ça évite en
particulier une quantité innombrable d'erreurs idiotes, tout en
posant des inconvénients minimaux au programmeur.
Après, on peut éventuellement préférer du typage statique
automatique, façon CaML, plutôt que du typage statique explicite
façon C, mais la charge de devoir écrire « int x » la première fois
est assez négligeable.
Tiens, un exemple : je suis en train de travailler sur le système de
gestion des adhérents d'une association. Dans la base de données,
chaque membre peut avoir plusieurs noms (ça sert surtout pour les
femmes mariées). Pour expédier du courrier, il faut choisir le quel
de ces noms on met sur l'enveloppe. Il y a des heuristiques, mais
surtout un champ dans la structure de données qui contient le nom. Ce
champ s'appelle nom_envoi. Mais j'avais oublié ça, et j'avais supposé
qu'il s'appelait envoi tout court, puisqu'il est de toutes façons
dans la structure nom. Le langage est à déclarations et typage
dynamique : il a accepté sans broncher que j'utilise ce champ sorti
de nulle part, et du coup le mécanisme ne marchait pas. Le bug n'a
été repéré que parce que la permanente de l'association fait son
boulot très consciencieusement et a vu l'erreur de nom sur certaines
des adresses.
Si j'avais utilisé un langage avec des déclarations statiques,
l'erreur aurait été vue immédiatement. Je considère que c'est une
déficience de ce langage que de ne pas permettre une telle analyse
statique du code. Évidemment, à côté de ça, ses avantages dans
d'autres domaines font que je persiste dans mon choix du langage,
mais s'il pouvait garder tous ses avantages _et_ avoir du typage
statique, ce serait infiniment mieux.
Michel Talon, dans le message
<itt792$oeb$2@asmodee.lpthe.jussieu.fr>, a écrit :
> Dans le même ordre d'idée il y a le typage
> automatique et
> dynamique des variables, comme en python, et qui n'existe pas en
> Java,
Là, je ne suis franchement pas d'accord du tout, pour la combinaison
de ces deux raisons :
- Dans un programme correctement écrit et débuggé, une variable n'a
qu'un seul type : si quelque part on écrit « a = x + 42 », c'est que
a et x sont des nombres (entiers ou flottants), et si ailleurs on
utilise a ou x comme des pointeurs ou des tableaux, c'est qu'il y a
un bug.
- Quand il y a un bug, il vaut mieux le détecter le plus tôt
possible, si possible au moment où le programme est compilé ou chargé
plutôt qu'au moment où l'endroit où se trouve l'erreur est exécuté.
Le typage statique des variables permet justement ça, et ça évite en
particulier une quantité innombrable d'erreurs idiotes, tout en
posant des inconvénients minimaux au programmeur.
Après, on peut éventuellement préférer du typage statique
automatique, façon CaML, plutôt que du typage statique explicite
façon C, mais la charge de devoir écrire « int x » la première fois
est assez négligeable.
Tiens, un exemple : je suis en train de travailler sur le système de
gestion des adhérents d'une association. Dans la base de données,
chaque membre peut avoir plusieurs noms (ça sert surtout pour les
femmes mariées). Pour expédier du courrier, il faut choisir le quel
de ces noms on met sur l'enveloppe. Il y a des heuristiques, mais
surtout un champ dans la structure de données qui contient le nom. Ce
champ s'appelle nom_envoi. Mais j'avais oublié ça, et j'avais supposé
qu'il s'appelait envoi tout court, puisqu'il est de toutes façons
dans la structure nom. Le langage est à déclarations et typage
dynamique : il a accepté sans broncher que j'utilise ce champ sorti
de nulle part, et du coup le mécanisme ne marchait pas. Le bug n'a
été repéré que parce que la permanente de l'association fait son
boulot très consciencieusement et a vu l'erreur de nom sur certaines
des adresses.
Si j'avais utilisé un langage avec des déclarations statiques,
l'erreur aurait été vue immédiatement. Je considère que c'est une
déficience de ce langage que de ne pas permettre une telle analyse
statique du code. Évidemment, à côté de ça, ses avantages dans
d'autres domaines font que je persiste dans mon choix du langage,
mais s'il pouvait garder tous ses avantages _et_ avoir du typage
statique, ce serait infiniment mieux.
Michel Talon, dans le message
<itt792$oeb$, a écrit :
> Dans le même ordre d'idée il y a le typage
> automatique et
> dynamique des variables, comme en python, et qui n'existe pas en
> Java,
Là, je ne suis franchement pas d'accord du tout, pour la combinaison
de ces deux raisons :
- Dans un programme correctement écrit et débuggé, une variable n'a
qu'un seul type : si quelque part on écrit « a = x + 42 », c'est que
a et x sont des nombres (entiers ou flottants), et si ailleurs on
utilise a ou x comme des pointeurs ou des tableaux, c'est qu'il y a
un bug.
- Quand il y a un bug, il vaut mieux le détecter le plus tôt
possible, si possible au moment où le programme est compilé ou chargé
plutôt qu'au moment où l'endroit où se trouve l'erreur est exécuté.
Le typage statique des variables permet justement ça, et ça évite en
particulier une quantité innombrable d'erreurs idiotes, tout en
posant des inconvénients minimaux au programmeur.
Après, on peut éventuellement préférer du typage statique
automatique, façon CaML, plutôt que du typage statique explicite
façon C, mais la charge de devoir écrire « int x » la première fois
est assez négligeable.
Tiens, un exemple : je suis en train de travailler sur le système de
gestion des adhérents d'une association. Dans la base de données,
chaque membre peut avoir plusieurs noms (ça sert surtout pour les
femmes mariées). Pour expédier du courrier, il faut choisir le quel
de ces noms on met sur l'enveloppe. Il y a des heuristiques, mais
surtout un champ dans la structure de données qui contient le nom. Ce
champ s'appelle nom_envoi. Mais j'avais oublié ça, et j'avais supposé
qu'il s'appelait envoi tout court, puisqu'il est de toutes façons
dans la structure nom. Le langage est à déclarations et typage
dynamique : il a accepté sans broncher que j'utilise ce champ sorti
de nulle part, et du coup le mécanisme ne marchait pas. Le bug n'a
été repéré que parce que la permanente de l'association fait son
boulot très consciencieusement et a vu l'erreur de nom sur certaines
des adresses.
Si j'avais utilisé un langage avec des déclarations statiques,
l'erreur aurait été vue immédiatement. Je considère que c'est une
déficience de ce langage que de ne pas permettre une telle analyse
statique du code. Évidemment, à côté de ça, ses avantages dans
d'autres domaines font que je persiste dans mon choix du langage,
mais s'il pouvait garder tous ses avantages _et_ avoir du typage
statique, ce serait infiniment mieux.
Le Fri, 24 Jun 2011 12:30:59 +0200,
remy écrivait :JKB a écrit :Le Wed, 22 Jun 2011 05:47:49 -0700 (PDT),
Aeris Imirhil écrivait :On 22 juin, 13:09, JKB wrote:Ton exemple est typiquement du goret-codage. D'une part, si tu ne
sais pas quel est la prototype de la fonction, tu ferais bi en de ne
pas l'utiliser.
Il ne s'agit pas de connaître uniquement le prototype de la fon ction
mais la signification exacte de sa valeur de retour : est-ce une
donnée de retour ou un code d'erreur ?
Ãa, mon grand, c'est spécifié dans le prototype et l' interface.
tien justement en parlent de truc a la con
voila se que je trouve dans uboot
void __show_boot_progress (int val)
{
return;
}
void show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
je devrait plutot dire
void inline __show_boot_progress (int val)
{
return;
}
void inline show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
Non.qui ne passe pas le compilateur
C'est parfaitement normal.
en gros l'on "surcharge "la fonction show_boot_progress
au lieux de faire le ménage dans le code cool non
Au lieu de passer pour un idiot, tu devrais aller te plonger dans la
doc de gcc. Enfin, je dis ça, je dis rien.
JKB
Le Fri, 24 Jun 2011 12:30:59 +0200,
remy <remy@fctpas.fr> écrivait :
JKB a écrit :
Le Wed, 22 Jun 2011 05:47:49 -0700 (PDT),
Aeris Imirhil <aeris.imirhil@gmail.com> écrivait :
On 22 juin, 13:09, JKB <j...@koenigsberg.invalid> wrote:
Ton exemple est typiquement du goret-codage. D'une part, si tu ne
sais pas quel est la prototype de la fonction, tu ferais bi en de ne
pas l'utiliser.
Il ne s'agit pas de connaître uniquement le prototype de la fon ction
mais la signification exacte de sa valeur de retour : est-ce une
donnée de retour ou un code d'erreur ?
Ãa, mon grand, c'est spécifié dans le prototype et l' interface.
tien justement en parlent de truc a la con
voila se que je trouve dans uboot
void __show_boot_progress (int val)
{
return;
}
void show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
je devrait plutot dire
void inline __show_boot_progress (int val)
{
return;
}
void inline show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
Non.
qui ne passe pas le compilateur
C'est parfaitement normal.
en gros l'on "surcharge "la fonction show_boot_progress
au lieux de faire le ménage dans le code cool non
Au lieu de passer pour un idiot, tu devrais aller te plonger dans la
doc de gcc. Enfin, je dis ça, je dis rien.
JKB
Le Fri, 24 Jun 2011 12:30:59 +0200,
remy écrivait :JKB a écrit :Le Wed, 22 Jun 2011 05:47:49 -0700 (PDT),
Aeris Imirhil écrivait :On 22 juin, 13:09, JKB wrote:Ton exemple est typiquement du goret-codage. D'une part, si tu ne
sais pas quel est la prototype de la fonction, tu ferais bi en de ne
pas l'utiliser.
Il ne s'agit pas de connaître uniquement le prototype de la fon ction
mais la signification exacte de sa valeur de retour : est-ce une
donnée de retour ou un code d'erreur ?
Ãa, mon grand, c'est spécifié dans le prototype et l' interface.
tien justement en parlent de truc a la con
voila se que je trouve dans uboot
void __show_boot_progress (int val)
{
return;
}
void show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
je devrait plutot dire
void inline __show_boot_progress (int val)
{
return;
}
void inline show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
Non.qui ne passe pas le compilateur
C'est parfaitement normal.
en gros l'on "surcharge "la fonction show_boot_progress
au lieux de faire le ménage dans le code cool non
Au lieu de passer pour un idiot, tu devrais aller te plonger dans la
doc de gcc. Enfin, je dis ça, je dis rien.
JKB
Le Fri, 24 Jun 2011 12:30:59 +0200,
remy écrivait :JKB a écrit :Le Wed, 22 Jun 2011 05:47:49 -0700 (PDT),
Aeris Imirhil écrivait :On 22 juin, 13:09, JKB wrote:Ton exemple est typiquement du goret-codage. D'une part, si tu ne
sais pas quel est la prototype de la fonction, tu ferais bi en de ne
pas l'utiliser.
Il ne s'agit pas de connaître uniquement le prototype de la fon ction
mais la signification exacte de sa valeur de retour : est-ce une
donnée de retour ou un code d'erreur ?
Ãa, mon grand, c'est spécifié dans le prototype et l' interface.
tien justement en parlent de truc a la con
voila se que je trouve dans uboot
void __show_boot_progress (int val)
{
return;
}
void show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
je devrait plutot dire
void inline __show_boot_progress (int val)
{
return;
}
void inline show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
Non.qui ne passe pas le compilateur
C'est parfaitement normal.
en gros l'on "surcharge "la fonction show_boot_progress
au lieux de faire le ménage dans le code cool non
Au lieu de passer pour un idiot, tu devrais aller te plonger dans la
doc de gcc. Enfin, je dis ça, je dis rien.
Le Fri, 24 Jun 2011 12:30:59 +0200,
remy <remy@fctpas.fr> écrivait :
JKB a écrit :
Le Wed, 22 Jun 2011 05:47:49 -0700 (PDT),
Aeris Imirhil <aeris.imirhil@gmail.com> écrivait :
On 22 juin, 13:09, JKB <j...@koenigsberg.invalid> wrote:
Ton exemple est typiquement du goret-codage. D'une part, si tu ne
sais pas quel est la prototype de la fonction, tu ferais bi en de ne
pas l'utiliser.
Il ne s'agit pas de connaître uniquement le prototype de la fon ction
mais la signification exacte de sa valeur de retour : est-ce une
donnée de retour ou un code d'erreur ?
Ãa, mon grand, c'est spécifié dans le prototype et l' interface.
tien justement en parlent de truc a la con
voila se que je trouve dans uboot
void __show_boot_progress (int val)
{
return;
}
void show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
je devrait plutot dire
void inline __show_boot_progress (int val)
{
return;
}
void inline show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
Non.
qui ne passe pas le compilateur
C'est parfaitement normal.
en gros l'on "surcharge "la fonction show_boot_progress
au lieux de faire le ménage dans le code cool non
Au lieu de passer pour un idiot, tu devrais aller te plonger dans la
doc de gcc. Enfin, je dis ça, je dis rien.
Le Fri, 24 Jun 2011 12:30:59 +0200,
remy écrivait :JKB a écrit :Le Wed, 22 Jun 2011 05:47:49 -0700 (PDT),
Aeris Imirhil écrivait :On 22 juin, 13:09, JKB wrote:Ton exemple est typiquement du goret-codage. D'une part, si tu ne
sais pas quel est la prototype de la fonction, tu ferais bi en de ne
pas l'utiliser.
Il ne s'agit pas de connaître uniquement le prototype de la fon ction
mais la signification exacte de sa valeur de retour : est-ce une
donnée de retour ou un code d'erreur ?
Ãa, mon grand, c'est spécifié dans le prototype et l' interface.
tien justement en parlent de truc a la con
voila se que je trouve dans uboot
void __show_boot_progress (int val)
{
return;
}
void show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
je devrait plutot dire
void inline __show_boot_progress (int val)
{
return;
}
void inline show_boot_progress (int val) __attribute__((weak,
alias("__show_boot_progress")));
Non.qui ne passe pas le compilateur
C'est parfaitement normal.
en gros l'on "surcharge "la fonction show_boot_progress
au lieux de faire le ménage dans le code cool non
Au lieu de passer pour un idiot, tu devrais aller te plonger dans la
doc de gcc. Enfin, je dis ça, je dis rien.
mais il semble d'après ce que tu dis
que si tu avais testé le point précis que tu as modifié tu aurais
découvert l'erreur.
Ce serait plutôt sur la possibilité qu'ils offrent d'écrire
des choses plus génériques, de plus haut niveau (jusqu'à "créer des
langages" avec un langage comme Lisp).
mais il semble d'après ce que tu dis
que si tu avais testé le point précis que tu as modifié tu aurais
découvert l'erreur.
Ce serait plutôt sur la possibilité qu'ils offrent d'écrire
des choses plus génériques, de plus haut niveau (jusqu'à "créer des
langages" avec un langage comme Lisp).
mais il semble d'après ce que tu dis
que si tu avais testé le point précis que tu as modifié tu aurais
découvert l'erreur.
Ce serait plutôt sur la possibilité qu'ils offrent d'écrire
des choses plus génériques, de plus haut niveau (jusqu'à "créer des
langages" avec un langage comme Lisp).
Ce champ s'appelle nom_envoi. Mais
j'avais oublié ça, et j'avais supposé qu'il s'appelait envoi tout court,
puisqu'il est de toutes façons dans la structure nom.
Ce champ s'appelle nom_envoi. Mais
j'avais oublié ça, et j'avais supposé qu'il s'appelait envoi tout court,
puisqu'il est de toutes façons dans la structure nom.
Ce champ s'appelle nom_envoi. Mais
j'avais oublié ça, et j'avais supposé qu'il s'appelait envoi tout court,
puisqu'il est de toutes façons dans la structure nom.
Ya pas de "ccommun des développeurs" en C : il n'y a que des bons. Les
autres, ils se rendent vite compte que "le C c'est trop compliqué, faut
gérer la mémoire et des pointeurs", et ils se mettent à faire du Java,
ou pire, du Python. Les plus gorets d'entre eux font du Perl ou du
Visual Basic.
Ya pas de "ccommun des développeurs" en C : il n'y a que des bons. Les
autres, ils se rendent vite compte que "le C c'est trop compliqué, faut
gérer la mémoire et des pointeurs", et ils se mettent à faire du Java,
ou pire, du Python. Les plus gorets d'entre eux font du Perl ou du
Visual Basic.
Ya pas de "ccommun des développeurs" en C : il n'y a que des bons. Les
autres, ils se rendent vite compte que "le C c'est trop compliqué, faut
gérer la mémoire et des pointeurs", et ils se mettent à faire du Java,
ou pire, du Python. Les plus gorets d'entre eux font du Perl ou du
Visual Basic.
> Ce serait plutôt sur la possibilité qu'ils offrent
> d'écrire
> des choses plus génériques, de plus haut niveau (jusqu'à "créer des
> langages" avec un langage comme Lisp).
Là, tu commets l'erreur de confondre typage dynamique et généricité.
On peut parfaitement faire des choses génériques en typage statique.
Tout au plus, ça alourdit légèrement la généricité intrusive (celle
où on regarde le type d'un objet et où on agit en conséquence), qui
est de toutes façons une mauvaise conception.
> Ce serait plutôt sur la possibilité qu'ils offrent
> d'écrire
> des choses plus génériques, de plus haut niveau (jusqu'à "créer des
> langages" avec un langage comme Lisp).
Là, tu commets l'erreur de confondre typage dynamique et généricité.
On peut parfaitement faire des choses génériques en typage statique.
Tout au plus, ça alourdit légèrement la généricité intrusive (celle
où on regarde le type d'un objet et où on agit en conséquence), qui
est de toutes façons une mauvaise conception.
> Ce serait plutôt sur la possibilité qu'ils offrent
> d'écrire
> des choses plus génériques, de plus haut niveau (jusqu'à "créer des
> langages" avec un langage comme Lisp).
Là, tu commets l'erreur de confondre typage dynamique et généricité.
On peut parfaitement faire des choses génériques en typage statique.
Tout au plus, ça alourdit légèrement la généricité intrusive (celle
où on regarde le type d'un objet et où on agit en conséquence), qui
est de toutes façons une mauvaise conception.
Avec beaucoup d'interfaces (pour ce qui concerne Java) ?
Euh... pas forcément, si tu fais des choses "vraiment
génériques" (disons de la méta-programmation).
Avec beaucoup d'interfaces (pour ce qui concerne Java) ?
Euh... pas forcément, si tu fais des choses "vraiment
génériques" (disons de la méta-programmation).
Avec beaucoup d'interfaces (pour ce qui concerne Java) ?
Euh... pas forcément, si tu fais des choses "vraiment
génériques" (disons de la méta-programmation).
>Ce serait plutôt sur la possibilité qu'ils offrent
>d'écrire
> des choses plus génériques, de plus haut niveau (jusqu'à "créer des
> langages" avec un langage comme Lisp).
Là, tu commets l'erreur de confondre typage dynamique et généricité.
On peut parfaitement faire des choses génériques en typage statique.
Avec beaucoup d'interfaces (pour ce qui concerne Java) ?Tout au plus, ça alourdit légèrement la généricité intrusive (celle
où on regarde le type d'un objet et où on agit en conséquence), qui
est de toutes façons une mauvaise conception.
Euh... pas forcément, si tu fais des choses "vraiment
génériques" (disons de la méta-programmation).
>Ce serait plutôt sur la possibilité qu'ils offrent
>d'écrire
> des choses plus génériques, de plus haut niveau (jusqu'à "créer des
> langages" avec un langage comme Lisp).
Là, tu commets l'erreur de confondre typage dynamique et généricité.
On peut parfaitement faire des choses génériques en typage statique.
Avec beaucoup d'interfaces (pour ce qui concerne Java) ?
Tout au plus, ça alourdit légèrement la généricité intrusive (celle
où on regarde le type d'un objet et où on agit en conséquence), qui
est de toutes façons une mauvaise conception.
Euh... pas forcément, si tu fais des choses "vraiment
génériques" (disons de la méta-programmation).
>Ce serait plutôt sur la possibilité qu'ils offrent
>d'écrire
> des choses plus génériques, de plus haut niveau (jusqu'à "créer des
> langages" avec un langage comme Lisp).
Là, tu commets l'erreur de confondre typage dynamique et généricité.
On peut parfaitement faire des choses génériques en typage statique.
Avec beaucoup d'interfaces (pour ce qui concerne Java) ?Tout au plus, ça alourdit légèrement la généricité intrusive (celle
où on regarde le type d'un objet et où on agit en conséquence), qui
est de toutes façons une mauvaise conception.
Euh... pas forcément, si tu fais des choses "vraiment
génériques" (disons de la méta-programmation).