Equivalent 'with' en C++? - Page 3

Pollux :
Mais bon, excuse-moi mais c'est pas comme si Pascal était une référence en terme de langage bien conçu, hein (bon, ça a été en grande partie corrigé par Delphi, je suis bien d'accord, mais je veux dire que ton argument d'autorité à propos des concepteurs de Pascal ne vaut pas grand-chose ^^)

Heu sans vouloir être vexant... Même si c'est pas ton langage favori ils ont quand même un tout petit peu plus de crédibilité que toi, moi, ou n'importe qui sur yN à ce point de vue, hein

Pour reprendre l'exemple de l'utilisateur avec des propriétés, c'est certain que yAro n'a *jamais* dû rajouter de champs aux profils yN parce qu'il avait tout bien conçu dès le départ

Probablement pas, mais t'es sûr que yAronet est un modèle de conception à suivre ? ^^
En admettant qu'il l'eut été, l'exemple est quand même mal choisi : j'ai la liste de champs en question, et le seul qui ne pouvait pas exister dans la 1ere version est celui qui indique le forum d'inscription. Or pour faire un peu d'histoire de yAronet, ça a quand même donné la v2 de yN et donc "quelques" changements de code (je sais pas quelle est la proportion qui a été conservée, mais ce champ en plus était à mon avis assez insignifiant par rapport au reste ^^)

Zephyr
:

Pollux :
Mais bon, excuse-moi mais c'est pas comme si Pascal était une référence en terme de langage bien conçu, hein (bon, ça a été en grande partie corrigé par Delphi, je suis bien d'accord, mais je veux dire que ton argument d'autorité à propos des concepteurs de Pascal ne vaut pas grand-chose ^^)

Heu sans vouloir être vexant... Même si c'est pas ton langage favori ils ont quand même un tout petit peu plus de crédibilité que toi, moi, ou n'importe qui sur yN à ce point de vue, hein

Je dis pas qu'on est plus malins qu'eux, loin de là (je ne prétends pas être capable de concevoir de fond en comble un langage entier), mais Pascal a été vivement critiqué à l'époque pour ses features pas très bien pensées (entre autres par le concepteur d'un langage qui s'appelait "C" ), donc ce n'est pas parce que "le concepteur de Pascal l'a choisi" que c'est, rétrospectivement, une bonne idée ^^ ("hindsight is always 20/20", comme disent les anglo-saxons : on a plus d'éléments pour juger rétrospectivement que dans le feu de l'action)

Pour reprendre l'exemple de l'utilisateur avec des propriétés, c'est certain que yAro n'a *jamais* dû rajouter de champs aux profils yN parce qu'il avait tout bien conçu dès le départ

Probablement pas, mais t'es sûr que yAronet est un modèle de conception à suivre ? ^^

Bah c'est un exemple d'application concrète, où les besoins évoluent au cours du temps, et je ne vois pas comment tu peux éviter ça avec une meilleure "conception"...

En admettant qu'il l'eut été, l'exemple est quand même mal choisi : j'ai la liste de champs en question, et le seul qui ne pouvait pas exister dans la 1ere version est celui qui indique le forum d'inscription. Or pour faire un peu d'histoire de yAronet, ça a quand même donné la v2 de yN et donc "quelques" changements de code (je sais pas quelle est la proportion qui a été conservée, mais ce champ en plus était à mon avis assez insignifiant par rapport au reste ^^)

Tiens, c'est marrant C'est si vieux que ça, "Afficher tous les connectés ?", "Ne pas afficher les signatures dans les posts ?", "Forcer position avatar :" et "Taille police (par défaut 10px) : :" ? (c'est une vraie question, hein)

Pollux :
Pascal a été vivement critiqué à l'époque pour ses features pas très bien pensées (entre autres par le concepteur d'un langage qui s'appelait "C")

, ça me rappelle une histoire d'hôpital et de charité je sais pas pourquoi...

Le C est un langage bas-niveau, mais il est plutôt bien conçu pour un langage bas-niveau, non ? Qu'est-ce que tu lui reproches ?

il dit juste que K&R ne sont pas forcement une bonne authorité pour juger un autre langage tel que le pascal

Ben, déjà, il s'agit des premières versions du C, pas du C iso si ? ie le truc sans les prototypes de fonctions, si je ne m'abuse ? si ça a été changé c'est sans doute qu'il y avait un problème...
à part ça je trouve que la syntaxe est pourrie mais je suis vaguement conscient que c'est subjectif, mais notamment le double emploi de la virgule est très bof selon moi. Sinon, le fait qu'une affectation soit une expression et pas juste un "statement", et qu'on puisse donc écrire des trucs comme if (i = 0), je n'en vois pas l'utilité, ça sert juste à rendre les programmes plus difficiles à lire quand on utilise cette feature (et à créer des bugs quand on l'utilise pas exprès ; je sais qu'il y a des warnings mais bon).
Il y a aussi la syntaxe des initialisations de tableaux qui est à chier, avec l'emploi des accolades et points-virgules qui n'a aucun rapport avec l'emploi normal. Et aussi (c'est un détail mais bon), les priorités des opérateurs << et >> sont complètement stupides...
ça te suffit ou tu en veux encore ? ^^

Le Pascal est bien plus propre de nombreux points de vue c'est vrai.
Mais il pèche par l'excès inverse je dirais, étant trop rigide ce qui est souvent contraignant. Sa gestion des pointeurs est un peu space aussi, mais c'est une question d'habitude tu me diras.

Ben ce n'était pas tant une question de propreté que de « features pas très bien pensées »

Pour être plus précis, j'ai vraiment du mal à comprendre le coup de la virgule. « e1, e2 » ça évalue e1, puis ça évalue e2, puis ça renvoie la valeur de e2 ; bon, très bien. Mais « e1; e2 », ça fait quoi, déjà ? ben, ça évalue e1 puis ça évalue e2... ah, oui, mais la différence c'est que ce n'est pas une expression valide, ça ne peut être utilisé que comme statement, et donc ça ne renvoie pas la valeur de e2. Mais ça coûterait quoi d'en faire une expression valide ? il me semble que ça ne coûterait rien du tout, c'est la signification usuelle du point-virgule, et je ne comprends vraiment pas pourquoi ils se sont fait chier à utiliser la virgule pour faire ça alors qu'elle sert déjà à séparer les arguments d'une fonction .
En fait, plus généralement, toute la distinction entre expressions et statements me semble assez fumeuse. "a = 3" n'a aucune raison d'être une expression valide, et inversement "<statement quelconque>; <expression>" n'a aucune raison de ne pas en être une à partir du moment où on accepte que les expressions aient des effets de bord... et si on ne l'accepte pas, alors "<expr>, <expr>" ne devrait pas exister (de toute façon ça ne servirait à rien ^^)

De la même façon, qu'est-ce que ça aurait coûté d'utiliser des crochets pour écrire les initialiseurs de tableaux plutôt que des accolades ? ben, rien, et ç'aurait été bien plus clair...

Bref, tout ça pour dire que le type qui a conçu cette chose critiquant vivement un autre langage pour ses features pas très bien pensées, hum, voilà quoi

Sally
: Ben, déjà, il s'agit des premières versions du C, pas du C iso si ? ie le truc sans les prototypes de fonctions, si je ne m'abuse ? si ça a été changé c'est sans doute qu'il y avait un problème...

(y en avait, mais seulement pour les types de retour)
Oui c'est vrai, d'un autre côté c'était exactement le même topo pour Pascal à l'époque je crois...
(peut-être une question de RAM ? les includes, ça peut en bouffer pas mal)

Et aussi (c'est un détail mais bon), les priorités des opérateurs << et >> sont complètement stupides...

En tant qu'opérateurs de multiplication/division, oui, mais en tant qu'opérateurs booléens, non... (sachant que les opérateurs booléens ont toujours une priorité plus basse que les opérateurs arithmétiques, ce qui est à peu près logique) Par contre la priorité des opérateurs &, | et ^ qui sont en-dessous des opérateurs de comparaison, je trouve ça profondément stupide, oui ^^ (mais en comparaison Pascal n'avait même pas d'opérateurs booléens... )

Sally :
Ben ce n'était pas tant une question de propreté que de « features pas très bien pensées »

Pour être plus précis, j'ai vraiment du mal à comprendre le coup de la virgule. « e1, e2 » ça évalue e1, puis ça évalue e2, puis ça renvoie la valeur de e2 ; bon, très bien. Mais « e1; e2 », ça fait quoi, déjà ? ben, ça évalue e1 puis ça évalue e2... ah, oui, mais la différence c'est que ce n'est pas une expression valide, ça ne peut être utilisé que comme statement, et donc ça ne renvoie pas la valeur de e2. Mais ça coûterait quoi d'en faire une expression valide ?

Rien du tout, et c'est vrai que c'est dommage... (mais Pascal n'est pas mieux de ce point de vue-là, c'est même plus grave puisqu'il y a nettement moins d'expressions valides)

et je ne comprends vraiment pas pourquoi ils se sont fait chier à utiliser la virgule pour faire ça alors qu'elle sert déjà à séparer les arguments d'une fonction .

Bah on peut faire exactement la même objection à Caml, qui fait un double emploi du point-virgule : comme séparateur dans les tableaux, et comme séparateur de statements (exactement comme la virgule en C, en fait )

En fait, plus généralement, toute la distinction entre expressions et statements me semble assez fumeuse. "a = 3" n'a aucune raison d'être une expression valide

J'ai l'impression que tu voudrais plutôt que ça soit une expression qui renvoie void, c'est pas tout à fait pareil ^^ Mais c'est assez utile de pouvoir faire "a = b = mafonction()", je trouve...

et inversement "<statement quelconque>; <expression>" n'a aucune raison de ne pas en être une à partir du moment où on accepte que les expressions aient des effets de bord...

Je suis bien d'accord...

De la même façon, qu'est-ce que ça aurait coûté d'utiliser des crochets pour écrire les initialiseurs de tableaux plutôt que des accolades ? ben, rien, et ç'aurait été bien plus clair...

En quoi ça aurait été plus clair ? Les crochets sont déjà utilisés dans les expressions pour indexer les tableaux, ça n'a pas grand-chose à voir avec définir un tableau... Les accolades, elles, sont utilisées comme délimiteurs, et je ne vois pas bien quel risque de confusion il pourrait y avoir entre des listes de statements séparés par des ; et le contenu d'un tableau
(sauf si {if(x)0;else 1;} était une expression valide, dans ce cas-là ça serait effectivement utile de prendre d'autres délimiteurs, mais ce n'est pas le cas; de toute façon si on avait expression=statement les parenthèses seraient les délimiteurs de blocs naturels, donc le problème ne se poserait pas)

Pollux :

En fait, plus généralement, toute la distinction entre expressions et statements me semble assez fumeuse. "a = 3" n'a aucune raison d'être une expression valide

J'ai l'impression que tu voudrais plutôt que ça soit une expression qui renvoie void, c'est pas tout à fait pareil ^^

Ben, ça dépend, mais en tous cas je ne trouve pas logique que ça ait un statut différent de « if(youpi) a = 3; », qui n'est pas une expression du tout. C'est vrai que je n'avais pas pensé au a = b = truc, mais tout "sucre syntaxique" est-il bon à prendre ? Enfin c'est vrai qu'avec les warnings le fait que ce soit une expression est moins gênant, mais bon. C'est quand même pas tellement plus long de mettre a = b à part (ou de faire a = (b = truc, b))

Pollux :
je ne vois pas bien quel risque de confusion il pourrait y avoir entre des listes de statements séparés par des ; et le contenu d'un tableau

Euh j'ai pas dit qu'il y avait un risque de confusion, c'est juste une question de facilité de lecture du code pour l'humain. D'habitude les accolades ça définit un compound statement, et là non. Mais à vrai dire le truc qui me dérange plus que la lisibilité c'est le fait qu'à cause de cette syntaxe (enfin c'est peut-être juste à cause du parser qui est pas doué, en fait ^^) tu ne peux pas mettre des "literals" de tableaux ailleurs que dans l'initialisation d'une variable, c'est pénible.

Sinon pour le point-virgule en caml, oui c'est le même problème ; ceci dit je pense qu'il est moins fréquent de vouloir mettre des expressions compliquées dans un "literal" liste que dans les arguments d'un appel de fonction, mais bon c'est quand même un peu pourri aussi c'est sûr... (mais le truc c'est que comme d'après moi l'une des utilisations de la virgule en C est inutile, ils auraient pu éviter le problème plus facilement ^^)

mais en comparaison Pascal n'avait même pas d'opérateurs booléens...

Bah....justement, c'est l'un des aspects dont je parlais : Pascal t'oblige à réfléchir et définir ce que tu vas faire.
Les opérateurs booléens sont booléens sur les types boolean, et bitwise sur les entiers (et interdits sur les autres types). Moi ça me semble plutôt logique comme définition.

Sally
:

Pollux :

En fait, plus généralement, toute la distinction entre expressions et statements me semble assez fumeuse. "a = 3" n'a aucune raison d'être une expression valide

J'ai l'impression que tu voudrais plutôt que ça soit une expression qui renvoie void, c'est pas tout à fait pareil ^^

Ben, ça dépend, mais en tous cas je ne trouve pas logique que ça ait un statut différent de « if(youpi) a = 3; », qui n'est pas une expression du tout.

Ben non, le fait que "if (foo) bar;" soit obligatoirement void n'est absolument pas un argument pour dire que "bar;" devrait être void, parce que "if (foo) bar;" est *obligatoirement* void quel que soit bar

C'est vrai que je n'avais pas pensé au a = b = truc, mais tout "sucre syntaxique" est-il bon à prendre ? Enfin c'est vrai qu'avec les warnings le fait que ce soit une expression est moins gênant, mais bon. C'est quand même pas tellement plus long de mettre a = b à part (ou de faire a = (b = truc, b))

Ouais alors là a = (b = truc, b), c'est vraiment moche pour le coup Enfin si je comprends bien la majorité de ton reproche c'est la possibilité d'une confusion avec ==, plus que la possibilité de pouvoir réutiliser la valeur qui a été affectée ?

Pollux :
je ne vois pas bien quel risque de confusion il pourrait y avoir entre des listes de statements séparés par des ; et le contenu d'un tableau

Euh j'ai pas dit qu'il y avait un risque de confusion, c'est juste une question de facilité de lecture du code pour l'humain. D'habitude les accolades ça définit un compound statement, et là non.[/cite]
Mouais, pas très convaincant je trouve... Les parenthèses en lisp (ou même en caml si on ne se sert pas de begin/end), tu trouves ça mieux ?

Mais à vrai dire le truc qui me dérange plus que la lisibilité c'est le fait qu'à cause de cette syntaxe (enfin c'est peut-être juste à cause du parser qui est pas doué, en fait ^^) tu ne peux pas mettre des "literals" de tableaux ailleurs que dans l'initialisation d'une variable, c'est pénible.

Alors ça c'est pour une tout autre raison que la syntaxe : à cause du typage statique, il faut bien pouvoir définir le type du tableau quelque part. Mais il y a une nouveauté de C99 qui permet d'utiliser des "literals" de tableaux partout, ça s'appelle les cast constructors :
mafonction((char *[]){"youp","la","boum"});

Sinon pour le point-virgule en caml, oui c'est le même problème ; ceci dit je pense qu'il est moins fréquent de vouloir mettre des expressions compliquées dans un "literal" liste que dans les arguments d'un appel de fonction, mais bon c'est quand même un peu pourri aussi c'est sûr... (mais le truc c'est que comme d'après moi l'une des utilisations de la virgule en C est inutile, ils auraient pu éviter le problème plus facilement ^^)

Non mais en fait la vraie raison c'est que mettre des virgules dans un paramètre de fonction est inutile puisque l'ordre d'évaluation des arguments est non-spécifié :

if (condition)
  f("hello",(a++,b),(dostuff(),42));

peut être transformé sans perte de généralité en

if (condition)
  a++, dostuff(), f("hello",b,42);

donc ce n'est pas nécessaire

spectras
:

mais en comparaison Pascal n'avait même pas d'opérateurs booléens...

Bah....justement, c'est l'un des aspects dont je parlais : Pascal t'oblige à réfléchir et définir ce que tu vas faire.
Les opérateurs booléens sont booléens sur les types boolean, et bitwise sur les entiers (et interdits sur les autres types). Moi ça me semble plutôt logique comme définition.

Euh, bitwise je voulais dire ^^ Le standard Pascal n'avait justement pas d'opération bitwise, ça doit être une extension dont tu parles...

Pollux :
Ben non, le fait que "if (foo) bar;" soit obligatoirement void n'est absolument pas un argument pour dire que "bar;" devrait être void, parce que "if (foo) bar;" est *obligatoirement* void quel que soit bar

Euh mon argument n'était pas si sophistiqué que ça, je disais juste que je trouve qu'une affectation n'a pas plus de raison de renvoyer quelque chose qu'un if. D'ailleurs c'est évident que if (foo) bar; ne peut pas avoir le type de bar, mais par contre il pourrait très bien renvoyer foo (je veux dire que c'est techniquement possible) et si ça se trouve on pourrait trouver une utilité à ça si c'était le cas, mais bon ^^.

Mais bon si tu veux un exemple plus sophistiqué tu peux prendre "if (foo) bar; else return;" : lui il pourrait avoir le type de bar .

Sinon, oui, c'est plus la possibilité d'utiliser par inadvertance = à la place de == et d'obtenir du code quand même valide qui me dérange

Pollux :
Non mais en fait la vraie raison c'est que mettre des virgules dans un paramètre de fonction est inutile puisque l'ordre d'évaluation des arguments est non-spécifié

Ah ok

Pollux :
Ben non, le fait que "if (foo) bar;" soit obligatoirement void n'est absolument pas un argument pour dire que "bar;" devrait être void, parce que "if (foo) bar;" est *obligatoirement* void quel que soit bar

Euh mon argument n'était pas si sophistiqué que ça, je disais juste que je trouve qu'une affectation n'a pas plus de raison de renvoyer quelque chose qu'un if. D'ailleurs c'est évident que if (foo) bar; ne peut pas avoir le type de bar, mais par contre il pourrait très bien renvoyer foo (je veux dire que c'est techniquement possible) et si ça se trouve on pourrait trouver une utilité à ça si c'était le cas, mais bon ^^.

Ah OK, j'avais pas vu ça sous cet angle-là... Enfin moralement "if (foo) bar; else bar;" devrait être en tout point équivalent à "bar;", donc je ne vois pas très bien comment foo pourrait intervenir dans la valeur de retour, même quand le membre de gauche et le membre de droite sont distincts ^^

Mais bon si tu veux un exemple plus sophistiqué tu peux prendre "if (foo) bar; else return;" : lui il pourrait avoir le type de bar .

(je suppose que tu veux dire "le type de foo")
Ben non, à moins bien entendu de détecter *exprès* ce type de cas
Je m'explique :

void f() {
  if (condition_f)
    bar;
  else
    halt();
}
void g() {
  if (condition_g)
    bar;
  else
    halt();
}

alors, il existe des valeurs de (condition_f,condition_g) tel que le compilo ne pourra pas savoir si condition_f est égale à condition_g ; or dans le cas condition_f=condition_g=vrai, "if (foo) f(); else g();" est équivalent à "if (foo) bar; else bar;", lequel devrait être équivalent à "bar;", qui est de type le type de bar. Donc "if (foo) f(); else g();" doit avoir au moins le type de bar, et pas celui de foo
Alors ensuite tu peux faire en sorte que le compilo adopte une sémantique radicalement différente selon que (condition_f,condition_g) est déterminable statiquement ou non, mais ça serait complètement idiot

Sinon, oui, c'est plus la possibilité d'utiliser par inadvertance = à la place de == et d'obtenir du code quand même valide qui me dérange

C'est un problème, mais on s'y fait vite (à condition de ne pas toucher à du caml entre temps ), et le fait que 90% des erreurs de ce style soient détectés par le warning de gcc aide quand même... Je pense que c'est quand même moins grave que les conséquences qu'auraient "i=0 est de type void", mais c'est vrai que si l'affectation avait été :=, ça aurait évité le problème ^^

Pollux :
Enfin moralement "if (foo) bar; else bar;" devrait être en tout point équivalent à "bar;", donc je ne vois pas très bien comment foo pourrait intervenir dans la valeur de retour, même quand le membre de gauche et le membre de droite sont distincts ^^

Hm, non, moralement il devrait être en tout point équivalent à "foo; bar;" plutôt

(je suppose que tu veux dire "le type de foo")

Euh je voulais bien dire le type de bar, ça n'avait pas de rapport direct avec ce que j'ai dit juste avant (qui était en fait une digression , c'est pour ça que ça commence par « d'ailleurs »), mais avec ce que j'avais dit encore avant ^^
c'est-à-dire que dans « je ne vois pas pourquoi "a = 3" a un statut différent de "if (youpi) a = 3;" » tu peux remplacer le deuxième par "if (youpi) a = 3; else return;" et là il n'y a vraiment plus de raison de les considérer différemment.
En fait tout à l'heure je n'avais pas pensé à cet exemple, juste à "if (youpi) a = 3; else a = 4;" mais je ne l'ai pas mis parce qu'on aurait pu m'objecter que si on veut que ce soit une expression il suffit d'écrire "a = youpi ? 3 : 4" donc c'est pas vraiment gênant. Alors qu'avec le return je ne vois pas trop comment on pourrait faire...

Sinon le "if (foo) ..." qui renverrait la valeur de foo j'ai juste dit qu'on pourrait s'amuser à décider que c'est le cas, pas que c'était intelligent, hein ^^. C'est juste pour dire que la valeur de retour d'un truc qui est censé ne faire que des effets de bord (comme une affectation ) c'est quelque chose que tu choisis un peu comme tu veux, enfin pour moi le fait que "a = bidule" renvoie la valeur de bidule est juste une convention, moralement c'est quand même void ; alors certes le fait que ça renvoie cette valeur a des avantages, mais si if (foo) renvoyait la valeur de foo on pourrait peut-être aussi trouver des cas où ça a des avantages, donc c'est un peu pareil (même si l'une de ces conventions est plus stupide que l'autre)

Sally
:

Pollux :
Enfin moralement "if (foo) bar; else bar;" devrait être en tout point équivalent à "bar;", donc je ne vois pas très bien comment foo pourrait intervenir dans la valeur de retour, même quand le membre de gauche et le membre de droite sont distincts ^^

Hm, non, moralement il devrait être en tout point équivalent à "foo; bar;" plutôt

Je me plaçais dans le cas où foo n'a pas d'effet de bord (ce qu'on peut supposer sans perte de généralité)

(je suppose que tu veux dire "le type de foo")

Euh je voulais bien dire le type de bar, ça n'avait pas de rapport direct avec ce que j'ai dit juste avant (qui était en fait une digression , c'est pour ça que ça commence par « d'ailleurs »), mais avec ce que j'avais dit encore avant ^^

Tiens, j'avais répondu comme si t'avais dit "le type de bar", mais ensuite je me suis dit que c'était stupide et que tu voulais probablement dire "le type de foo", donc j'ai édité (et pour "le type de foo", ce n'était pas du tout idiot, puisque c'était en conséquence directe de "le type/la valeur de if (foo) machin; peut dépendre de foo")

c'est-à-dire que dans « je ne vois pas pourquoi "a = 3" a un statut différent de "if (youpi) a = 3;" » tu peux remplacer le deuxième par "if (youpi) a = 3; else return;" et là il n'y a vraiment plus de raison de les considérer différemment.

Oui, je suis parfaitement d'accord C'est ce que fait Caml (le type de "return;" est 'a), ou de façon équivalente tu peux aussi considérer que c'est "if (!youpi) return; bar;", qui a exactement le type de "bar;" ^^

En fait tout à l'heure je n'avais pas pensé à cet exemple, juste à "if (youpi) a = 3; else a = 4;" mais je ne l'ai pas mis parce qu'on aurait pu m'objecter que si on veut que ce soit une expression il suffit d'écrire "a = youpi ? 3 : 4" donc c'est pas vraiment gênant. Alors qu'avec le return je ne vois pas trop comment on pourrait faire...

Ah mais je ne dis pas que les statements devraient être distincts des expressions, au contraire ; je ne vois pas bien ce que tu essayes de dire
(et avec le return c'est parfaitement possible avec des expressions aussi :

void plouf() {
    if (setjmp(buf))
        return;
    ...
    a = youpi ? 3 : (longjmp(buf,1),42);
    ...
}

)

Sinon le "if (foo) ..." qui renverrait la valeur de foo j'ai juste dit qu'on pourrait s'amuser à décider que c'est le cas, pas que c'était intelligent, hein ^^. C'est juste pour dire que la valeur de retour d'un truc qui est censé ne faire que des effets de bord (comme une affectation ) c'est quelque chose que tu choisis un peu comme tu veux, enfin pour moi le fait que "a = bidule" renvoie la valeur de bidule est juste une convention, moralement c'est quand même void

Ah, une fonction qui a des effets de bord n'est pas censé renvoyer une valeur

alors certes le fait que ça renvoie cette valeur a des avantages, mais si if (foo) renvoyait la valeur de foo on pourrait peut-être aussi trouver des cas où ça a des avantages, donc c'est un peu pareil (même si l'une de ces conventions est plus stupide que l'autre)

Oui, je suis d'accord sur le fait que c'est une convention (on pourrait, je sais pas, renvoyer la valeur précédente de la variable, même si ça serait un peu stupide -- quoique, on pourrait échanger x et y avec x=y=x ), mais elle est particulièrement intéressante dans le sens où, de même que la notation "let x = y" en caml est justifiée par le fait que x=y par la suite, la notation "x = y = z;" en C est justifiée par le fait que x=y=z par la suite, ce qui n'est vrai qu'avec cette convention

ouch ma discussion qui servait à rien, perdue au milieu de plein d'autres
en plus si vous vous mettez à donner toutes les raisons pour lesquelles le C est mal fichu, ça risque de faire quelques pages ^^

[cite]Pollux :
Je dis pas qu'on est plus malins qu'eux, loin de là (je ne prétends pas être capable de concevoir de fond en comble un langage entier), mais Pascal a été vivement critiqué à l'époque pour ses features pas très bien pensées (entre autres par le concepteur d'un langage qui s'appelait "C" ), donc ce n'est pas parce que "le concepteur de Pascal l'a choisi" que c'est, rétrospectivement, une bonne idée ^^[cite]
Je ne dis pas que le pascal était bien pensé au départ, mais le with a été pris dans Delphi également (d'ailleurs il a davantage de raisons d'exister, avec l'apparition des objets) : si c'était vraiment si mauvais ils l'auraient surement supprimé, c'était le moment où jamais.

Bah c'est un exemple d'application concrète, où les besoins évoluent au cours du temps, et je ne vois pas comment tu peux éviter ça avec une meilleure "conception"...

En prévoyant à l'avance les features qu'on veut, et les champs nécessaires pour les coder ? Les seules qui ne sont pas faisables sont celles qui dépendent de modules qui n'existent pas encore au moment de la conception (cf cite suivant)

Tiens, c'est marrant C'est si vieux que ça, "Afficher tous les connectés ?", "Ne pas afficher les signatures dans les posts ?", "Forcer position avatar :" et "Taille police (par défaut 10px) : :" ? (c'est une vraie question, hein)

Non, mais tu n'as pas lu ce que j'ai dit (pr changer) : ce sont des features qui ne dépendent de rien qui n'existait pas à la création de yAronet (contrairement à ce qui touche aux forums, qui sont apparus plus tard), dont elles auraient pu (du, amha) être prévues dès le départ ^^

Zephyr
:

Tiens, c'est marrant C'est si vieux que ça, "Afficher tous les connectés ?", "Ne pas afficher les signatures dans les posts ?", "Forcer position avatar :" et "Taille police (par défaut 10px) : :" ? (c'est une vraie question, hein)

Non, mais tu n'as pas lu ce que j'ai dit (pr changer) : ce sont des features qui ne dépendent de rien qui n'existait pas à la création de yAronet (contrairement à ce qui touche aux forums, qui sont apparus plus tard), dont elles auraient pu (du, amha) être prévues dès le départ ^^

Bah pas forcément, ça suit l'évolution des skins, des demandes des utilisateurs, etc... (peut-être qu'on peut aussi vouloir afficher les infos du profil dans chaque post ? pourtant l'option n'existe pas, est-ce qu'elle aurait dû être prévue dès le départ à ton avis ?)

D'ailleurs le fait de permettre ou non de cacher certains éléments est un facteur important dans la façon dont les gens vont interagir sur un forum (de même que d'autres facteurs comme l'espacement entre les posts, ou la présence d'un formulaire directement en bas de la page), en changeant par exemple leur propension à écrire un post même s'il est court, ou qu'il n'apporte pas grand chose, ou au contraire leur propension à faire des gros trolls cite-point-par-point ; donc ce genre de feature ne peut pas être prévu directement au début, et doit évoluer en fonction des gens qui fréquentent le forum, et de la façon dont ils s'en servent ^^

EDIT : voilà un article qui parle un peu du sujet
(EDIT2 : oups, mauvais lien, corrigé)

Pollux :
Ah mais je ne dis pas que les statements devraient être distincts des expressions, au contraire ; je ne vois pas bien ce que tu essayes de dire

Euh j'essayais de rien dire de plus, tout ça ça commentait la phrase « toute la distinction entre expressions et statements me semble assez fumeuse. » ^^ Le seul truc c'est que j'ai dit « puisque le if blabla n'est pas une expression valide, alors je ne vois pas pourquoi l'affectation en est une », donc superficiellement ça peut donner l'impression que je ne suis pas d'accord avec toi, mais en fait c'est juste la contraposée de ce que tu dis toi ^^

Pollux :
Ah, une fonction qui a des effets de bord n'est pas censé renvoyer une valeur

Non, c'est pas ce que j'ai dit, j'ai dit que si l'utilité de cette fonction réside dans ses effets de bord, la valeur de retour peut être choisie de différentes manières sans que ça modifie la, euh, fonction de la fonction. « moralement, c'est void » ça veut juste dire que, dans l'idée, la valeur de retour n'est pas le « résultat » de la fonction mais plutôt un indicateur sur ce qu'elle a fait, le résultat de la fonction étant ses effets de bord ; et dans 99% des cas tu n'utiliseras d'ailleurs pas la valeur de retour.

ok enfin c'est très souvent le cas en C (sprintf, memcpy, etc...) [*]. Et dans d'autres langages c'est encore "pire", en Ruby tous les statements sont des expressions, et en général ils renvoient une valeur (donc si une méthode d'un objet renvoie "moralement" void, elle renvoie plutôt this en Ruby pour pouvoir enchaîner les appels : associative_array[key].sort!.uniq! [les ! veulent dire que la fonction modifie l'objet sur place, plutôt que de renvoyer un objet modifié] je crois que c'était pareil en Smalltalk, qui est assez proche de Ruby)
D'ailleurs c'est marrant la façon dont caml fait exactement le contraire en encourageant vivement les trucs qui sont "moralement" void à rester void Le problème c'est qu'il y a un gros gros paquet de fonctions qui sont intermédiaires, i.e. une fonction avec des effets de bords qui renvoie une valeur qui dans certains cas est "moralement" inutile à l'appelant par exemple parce qu'on sait déjà ce qu'elle va retourner, et qui dans d'autres est cruciale...


[*] en fait, certains vieux compilateurs devaient faire un warning quand on appelait une fonction qui renvoie autre chose que void (le code source du compilo sur lequel CC et GTC sont basés était bourré d'un nombre hallucinant de (void)fonction(); pour éviter ça ), mais ils ont dû se rendre compte que c'était plus chiant qu'autre chose ^^

En caml quand une fonction intermédiaire (cad suivie d'un ";") avec effets de bord renvoie autre chose que "void", il faut l'inclure dans un appel à ignore, sinon le compilateur sort un warning.

Pollux
: Bah pas forcément, ça suit l'évolution des skins, des demandes des utilisateurs, etc... (peut-être qu'on peut aussi vouloir afficher les infos du profil dans chaque post ? pourtant l'option n'existe pas, est-ce qu'elle aurait dû être prévue dès le départ à ton avis ?)

(des skins je passe sur celle là, j'ai pas du comprendre ce que tu veux dire)
Le forum est plutôt un bon exemple puisqu'il a vraiment tendance à gagner des features très rapidement, avec des suggestions dans tous les sens (enfin... en théorie ); mais justement, si c'était bien conçu, chaque feature ne devrait demander qu'une toute petite quantité de code, au pire une nouvelle méthode dans un des objets, mais le namespace ne devrait pas changer du point de vue du "with" (sauf si la méthode en question se trouve dans l'objet qui possède la méthode qui contient le "with", mais ça réduit considérablement les "efforts" à faire pour éviter les conflits, d'ailleurs je trouverais normal que le "this." ou "this->" soit obligatoire pr acceder aux attributs et méthodes des objets, ce qui éliminerait totalement les conflits, pr le coup)

D'ailleurs le fait de permettre ou non de cacher certains éléments est un facteur important dans la façon dont les gens vont interagir sur un forum (de même que d'autres facteurs comme l'espacement entre les posts, ou la présence d'un formulaire directement en bas de la page), en changeant par exemple leur propension à écrire un post même s'il est court, ou qu'il n'apporte pas grand chose, ou au contraire leur propension à faire des gros trolls cite-point-par-point ; donc ce genre de feature ne peut pas être prévu directement au début, et doit évoluer en fonction des gens qui fréquentent le forum, et de la façon dont ils s'en servent ^^

Yep, ça rejoint ma réponse à la question précedente, on peut détailler un peu plus. En admettant que yN soit programmé avec une vision objet (je ne pense pas que ça soit le cas, mais peu importe), les champs des différentes classes devraient alors grosso modo ressembler fortement aux tables respectives de la base sql (qui elle, pour le coup, a plutôt interet à ne pas trop bouger au fil du temps; on y reflechit à 2 fois avant d'ajouter un nouveau champ à une table qui contient déjà des milliers d'enregistrements ^^). Du coup, les classes elles-mêmes sont relativement fixées : si la base est fixée, les classes le sont aussi; à moins d'ajouter des attributs qui sont calculables à partir d'autres attributs pour gagner du temps je ne sais où, les nouvelles features ne vont nécessiter au "pire" que des nouvelles méthodes, et bien sûr pas de changements en global, donc a priori pas de problèmes.

./82 > -ws pawa ^^ (surtout si tu utilises une bibliothèque du genre de lablgtk). Mais ce warning (même si personnellement je ne l'aime pas) est justifié par le fait que, de la façon dont sont conçues les fonctions standard (qui normalement, comme a dit Pollux, renvoient unit si leur utilité réside dans les effets de bord), il est relativement probable que si tu jettes une valeur qui n'est pas de type unit c'est que tu as oublié quelque chose. D'ailleurs cette convention (encourager les fonctions moralement void à être vraiment void) est justifiée par le fait qu'en caml le type d'une fonction est une indication importante sur ce qu'elle fait ; disons que quand une fonction renvoie unit on peut presque considérer ça comme un élément de documentation (« cette fonction sert à avoir des effets de bord »)
(en lablgtk, dès que tu enregistres un callback sur un événement, tu récupères un identifiant ou je sais plus trop quoi qui te permet le cas échéant de dés-enregistrer ce callback, mais 99% du temps ça sert à rien et généralement tu vas enregistrer des callbacks en série, donc -ws powa vraiment ^^)

Moumou :
En caml quand une fonction intermédiaire (cad suivie d'un ";") avec effets de bord renvoie autre chose que "void", il faut l'inclure dans un appel à ignore, sinon le compilateur sort un warning.

C'est exactement ce dont je parlais, oui

Zephyr
: au pire une nouvelle méthode dans un des objets, mais le namespace ne devrait pas changer du point de vue du "with"

Ben une préférence en plus, ça rajoute forcément un champ...

Yep, ça rejoint ma réponse à la question précedente, on peut détailler un peu plus. En admettant que yN soit programmé avec une vision objet (je ne pense pas que ça soit le cas, mais peu importe), les champs des différentes classes devraient alors grosso modo ressembler fortement aux tables respectives de la base sql (qui elle, pour le coup, a plutôt interet à ne pas trop bouger au fil du temps; on y reflechit à 2 fois avant d'ajouter un nouveau champ à une table qui contient déjà des milliers d'enregistrements ^^).

Pourquoi donc ? C'est vraiment si coûteux que ça de rajouter un champ à chaque profil ?
(et quand bien même ça serait effectivement coûteux, on peut envisager d'autres solutions pour rajouter un flag, du style avoir un champ de flags dans la table sql pour les préférences : mais le namespace de l'objet, lui, aurait bien un champ en plus ^^)

Ben je ne pense pas que le warning "non-unit statement" soit la cause du fait que les fonctions à effets de bord renvoient unit, plutôt une conséquence (sachant que c'est le cas, il est en effet relativement probable qu'un "non-unit statement" corresponde à une erreur dans le code, donc ils ont jugé utile de mettre un warning). La cause ça peut être en partie ce que j'ai dit sur la documentation, mais il y a aussi une raison plus profonde je pense avec le fait que les deux branches d'un if sont obligées d'avoir le même type, donc si chaque fonction à effet de bord renvoyait un peu n'importe quoi on serait souvent obligé de jeter explicitement la valeur de retour, ce qui serait un peu lourd...

Ah oui, c'est une très bonne raison... C'est vrai que ça obligerait à ce que l'inférence de type ne soit pas purement bottom-up... (i.e. il faudrait par exemple propager de façon top-down un flag qui précise si la valeur est utilisée ou pas)

Enfin ça pourrait être géré autrement ; par exemple en C modifié pour que statement=expression, on pourrait avoir "c ? a : b" pour le if de caml (la valeur de retour compte), et "if (c) a else b" pour le if du C (qui serait en fait une abréviation de "c ? (void)a : (void)b"), ce qui serait en accord avec la distinction que fait le C entre ?: et if ^^

Hum pour le Pascal je sais pas si c'est ou non une extension. Pour moi le Pascal c'est toujours resté Borland Turbo Pascal v5

Pollux
: Ben une préférence en plus, ça rajoute forcément un champ...

champ de bits ?
en plus c'est le cas très spécifique du sql où les élements d'un tuple sont des cardinaux, si tu utilises un langage "normal", tu peux mettre tes preferences dans un enregistrement "preferences" à l'interieur de ta classe, et alors tu peux en ajouter autant que tu veux sans aucun problème

Pourquoi donc ? C'est vraiment si coûteux que ça de rajouter un champ à chaque profil ?

Non, mais c'est mauvais signe si chaque petite modif t'en fait rajouter un (on revient à l'idée de structure qui devrait être un minimum pensée à l'avance, etc).

(et quand bien même ça serait effectivement coûteux, on peut envisager d'autres solutions pour rajouter un flag, du style avoir un champ de flags dans la table sql pour les préférences : mais le namespace de l'objet, lui, aurait bien un champ en plus ^^)

cf. 1er cite

bon ben "agree to disagree" alors, parce qu'essayer de caser toutes les préférences futures dans un champ de bit de taille fixe, personnellement je trouve que c'est un gros hack (qui peut éventuellement être utile si comme tu l'affirmes la base de donnée n'est pas extensible, mais la modélisation objet devrait au moins en faire abstraction)