+ Répondre à la discussion Actualité déjà publiée
Page 7 sur 8 PremièrePremière ... 345678 DernièreDernière
  1. #121
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    4 069
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 4 069
    Points : 8 944
    Points
    8 944

    Par défaut

    C'est effectivement une définition que l'on peut choisir.
    une des définitions donnée est celle-ci
    les conversions implicites de types sont formellement interdites. Si de telles conversions sont possibles, le langage est faiblement typé.
    dans ce cas Java est faiblement typé car
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
             Integer i = 5;
             String a = "test : " + i;
    Le puriste de Java me dirons que dans ce cas c'est la méthode Integer.toString(); je réponds tout comme en javascript et dans ne nombreux langage.

    une autre définition parfois combiné avec la précédente parfois non est
    la compilation ou l'exécution peuvent détecter des erreurs de typage. Si ces erreurs ne sont jamais reconnues, le langage est faiblement typé
    Lorque je fais si cela me retourne NaN (Not a Number)
    Ais-je détecté que le type est incorrect ?
    Math.sin étant une méthode don la signature prends tout objet y a-t-il eu une erreur non détecté ?
    JS serait-il fortement typé si tout d'un coup aulieu d'utiliser la LIB standard j'en utilisait une qui vérifie le type de Math.sin ?
    Que dire des fonction qui retourne une code 0 1 -1 et ne lève aucune exception ?

    Je trouve que tous cela est bien plus ambigüe qu'il n'y parait.
    Si je réuni ces deux définitions j'aurais tendence à dire que JS est faiblement typé.

    Mais je peux choisir d'autre définition. par exemple
    Un langage est faiblement Typé s'il autorise un objet à changer de type au cours de sa vie.
    de tels langages existes. je pourais faire
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    Object a = new Integer(5);
    Integer b = a;
    typeof a; // Integer
    log(b); //5
    a.toString();
    String c = a;
    typeof a; // String
    log(b); //null
    log(c); //"5"
    dans un tel exemple les référence a b et c ne change jamais de nature. un copilateur type Java pourait donc vérifier les type et ne trouverait aucune erreur de type.
    pourtant l'objet à changé de nature en cours de route.
    si je prends les deux première définition ce langage est fortement typé. si je prends la dernière JS est fortement typé.
    qui croire ?

    Benjamin C. Pierce American professor of computer science at the University of Pennsylvania.
    author of one book on type systems, Types and Programming Languages ISBN 0-262-16209-1. has also edited a collection of articles to create a second volume Advanced Topics in Types and Programming Languages ISBN 0-262-16228-8. à dit
    J'ai passé quelques semaines à essayer de clarifier les terminologies « fortement typé », « statiquement typé », « sûr », etc., et j'ai trouvé cela extraordinairement difficile… L'utilisation de ces termes est si diverse qu'elle les rend presque inutiles.
    Je suis du même avis. Sur la grosse centaine de langage que je connais (plus ou moins bien) la diversité est telle que je suis incapable de choisir une définition de fortement typé ou faiblement typé.
    Je préfère comprends le typage du langage que de savoir s'il est fortement ou faiblement typé.
    pour moi le typage le plus faible est
    Un langage est faiblement Typé s'il autorise un objet à changer de type au cours de sa vie.
    à l'opposé le plus fort typage est celui qui interdit toute utilisation d'un type à la place d'un autre. et qui donc impose à chaque objet le nécéssitant la présence d'une méthode explicite (comme toString() en Java) appellée explicitement.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    String a = "test : " + i.toString();
    entre les deux existe une multitude de définition qui donne une palette de couleur au choix.
    A+JYT

  2. #122
    Inactif
    Homme Profil pro
    Collégien
    Inscrit en
    octobre 2012
    Messages
    78
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : octobre 2012
    Messages : 78
    Points : 0
    Points
    0

    Par défaut

    Disons qu'on s'en fiche un peu, de la force du typage .

  3. #123
    Membre chevronné
    Avatar de la.lune
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    décembre 2010
    Messages
    534
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Comores

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2010
    Messages : 534
    Points : 2 029
    Points
    2 029

    Par défaut

    Citation Envoyé par sekaijin Voir le message
    C++ qui est communément admi comme fortement typé permet d'écrire
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    a=new Array()+new Number(4)-new String("2")+new Boolean(true)
    . cela ne fait pas de C++ un langage faiblement typé.
    Impossible de faire un truc pareil en C++, les opérateurs surchargés s'appliquent tout simplement sur les références des vers les objets, mais pas sur les objets elles même ou non plus sur des pointeurs comme ça, l'opérateur new en C++ fait une instanciation dynamique et retourne un pointeur sur l'objet.

    Et l'instanciation normale ne se fait même pas comme en Java et JavaScript. Mais comme MaClass objet(pramsduconstructeur); du coup impossible d'appliquer directement un opérateur directement sur l'objet qu'on vient de créer. On peut à la rigueur accéder en faisant faire appel aux références des objets comme ça:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    class A {int a;
    public:
     A(int b){
    this->a=b;
    };
    A operator +(A a){
    this->a=this->a+a.a;
    return *this;
    }
    int getVal(){
    return a;}
     
     
    void affiche(ostream &flux) const{
    flux<<a<<"\n";
    };
     
     
    };
    std::ostream &operator<<(std::ostream &flux, A const& a)
    {
        a.affiche(flux) ;
        return flux;
    }
    Ainsi dans Main je pourrais faire appel au références sur les objets
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    A a(2);A b(3);
    a=(*new A(3))+(*new A(3));
    cout<<"a="<<a;
    a=6
    Le plus important ici, c'est qu'il doit exister une définition préalable de l’opérateur + ce qui n'a rien n'avoir avec la définition standard du lagunage, donc un contrat qu'on définit entre les références, et l'opérateur joue juste le rôle d'un simple nom de méthode qu'on va appeler.

    Mais pourquoi JavaScript se donne le droit d'appeler des opérateurs sur d'autres objets sémantiquement aucun sens, pas de contrat défini, sans se soucier des dangers qui peuvent exister alors que ça donne des codes dépourvus de toute sens, à quoi ça sert vraiment de définir des types pour nos objets s'ils peuvent être placés n'importe où.
    Quand je définis l'opérateur moi même les gens saurons que j'ai changé ce qui se passe dans le normale. En JS on ne comprend rien du tout. Des appels statiques des opérateur sur toute chose.

    En javaScript tout comme en Java lorsque tu crée un Objet il a un certain type et celui-ci ne changera jamais jusqu'à sa destruction
    Mais il faut bien dire l'objet indépendamment de là où il est stocké, car déjà l'objet en soi je ne peux pas le modifier c'est comme vouloir faire:
    new Array()=12 ou faire même si je veux écraser l'ancien new Array(1,2,3)=new Array(0,1);, il va refuser
    Ici il sait dire "Ah cette assignation n'est pas autorisée", et ben tout simplement par ce que ce sont des objet et c'est le moment de la création des objets eux même et pourtant il permet de faire le bordel en manipulation.

    Par contre en C++ vu que l'exemple précédant je travaillais comme avec des variables, je peux faire facilement comme ça:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    cout<<"a="<<(*new A(3)=*new A(5));
    a=5
    En 2e lieu je crois qu'on mélange dans le débat, mais qui vous a dis que typage dynamique est synonyme de faiblement typé c'est juste les variables qui ne sont pas typés statiquement, mais le problème en JavaScript se pose sur les contenus des variables et des objets, comment les moteurs JavaScript sont aussi con de ne pas pourvoir dire que tout ceci n'a pas de sens:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    a=new Array()+new Number(4)-new String("2")+new Boolean(true)
    Citation Envoyé par sekaijin Voir le message
    JavaScript est assez intelligent pour que tu n'ai pas à écrire le cast
    Je n'appel pas ça de l’intelligence mais l'inexistence de typage lui oblige, et gare à nous au contenu, JavaScript n'est pas responsable.

    Moi je vois là, une faiblesse car au préalable JavaScript, nous dit la règle suivante: "Moi JavaScript: je ne m'intéresse pas aux types des données que vous me fournissez, moi j'évalue tout juste les contenus que je trouve dans les variables ou placés explicitement dans les instructions et puis je regarde l'opérateur, alors si j'arrive à vous retourner quelque chose tant mieux pour vous, sinon je vais vous insérer ou retourner un bon NaN dans vos résultats et tant pis pour vous, débrouillez vous je ne suis pas là pour faire du social".

    Alors là je dois suivre le jeu en tant que développeur aussi JavaScript et je dis ok ok JS ne se soucie pas alors je vais pouvoir faire tout ce que je veux, mais si je me trompe un jour j'aurais un bon et je ne saurais jamais où est tel.

    Moi si on me dit d'écrire un compilateur de JavaScript je serais très content car le jeu est très simple je ne suis pas obligé de dire que quoi que se soit ni lever une exception.

    Ce me casse la tête c'est qu'en JavsScript je ne peux même pas tester si ce foutu NaN existe ou pas avant de décider que si l'instruction a pu en sa totalité la retourner, car en toute malhonnêteté intellectuelle JS a l’audace de considérer NaN comme "A" ou 2. Ce qui fait que entre le debut de l'instruction et le point virgule il peut y avoir un NaN quelque part c'est simple il va l'insérer dans le résultat.

    Un petite exemple si l'utilisateur aura à insérer des nombres à virgule ou moi même j'ai oublié dans une variable de type string contenant le nombre venant du serveur ou en entrée, donc si je me trompe je fais b="2,5" au lieu de b="2.5" et puis je fais
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    b="2,5";
    var result="VAL"+12/b+2*2+"FINAL";
    result="VALNaN4FINAL"
    C'est ça ce que vous appelez détecter une erreur de type, au lieu de me déclencher une erreur, mon utilisateur a devant lui un bon NaN inséré dans le résultat.
    dans ce cas Java est faiblement typé carCode :
    Sélectionner tout - Visualiser dans une fenêtre à part

    1
    2
    Integer i = 5;
    String a = "test : " + i;
    Il n y a pas de conversion implicite ici, il y a de la concaténation combien de fois on va vous répéter la même chose, si je fais:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    String a = "test : " + 1;
    où est la conversion implicite, Java permet de faire pour les types primitifs et ça s’arrête là.
    Une conversion implicite c'est qu'on pusse faire des calculs sur des chaines, ÇA N'EXISTE PAS EN JAVA
    Je ne peux pas faire
    Mais quand tu dis ceci:
    a= Math.sin("t");si cela me retourne NaN (Not a Number)
    Ais-je détecté que le type est incorrect ?
    Mais que ce que tu veux qu'il fasse le "t"? Dis moi? La première règle en programmation "TOUTE INSTRUCTION DOIT RETOURNER QUELQUE CHOSE" ou moins rompre le programme. NaN est une valeur, je peux faire NaN.toString()=="NaN", contrairement à undefinned que je ne peux pas faire undefined.toString(). Et JavaScript ne renvoi quelque chose de type undefinded, sauf une pour variable non initialisés ou qui sont vides si là ils pointaient est détruit. POINT BARRE
    On n'appelle pas ça détecter une erreur, il ne sait rien faire avec le "t" donc il se débrouille pour renvoyer une valeur moche et polluer mon programme

    Détecter une erreur c'est le signaler, rompre le programme pour ces irrégularités de type ou au moins un warning, quelque chose comme ça mais pas le silence. Une raison de plus que je serais le premier candidat pour l’écriture d'un moteur de JavaScript, comme le jeu est aussi simple que ça.

    dans un tel exemple les référence a b et c ne change jamais de nature. un copilateur type Java pourait donc vérifier les type et ne trouverait aucune erreur de type.
    pourtant l'objet à changé de nature en cours de route.
    Je m'excuse mais là à présent vous commencez à dire des chose que je ne comprend pas du tout.
    Tu reviens sur la même discussion qu'une VARIABLE DE TYPE OBJET PEUT CHANGER DE RÉFÉRENCE VERS UN AUTRE OBJET EN COURS ROUTE, et non pas l'objet avec un type déjà défini ou avec lequel on a assigné une valeur. Est ce que ça à changer de type en cours de route, il est resté et restera toujours de type Object jusqu'a la fin du programme. Mais essaye de Changer c ou b pour voir

    Déjà je me demande quelque langage que si je fais a.toString(); alors a devient de type String? C'est quel langage ça, c'est complètement ABSURDE et IMPOSSIBLE à moins que toString() ne soit pas une méthode d'instance, une sorte de méthode static surchargé syntaxiquement comme les méthodes d’extension de C#. Comment une méthode d'instance appeler sur un objet, va détruire l'instance elle même et faire appel à une autre instance d'un autre type et l'affecter à cette variable elle même. C'est de la magie ça.

    Une instruction comme ça this=new MaClass() c'est peut être chez les extra-terrestres. Si tu me dit qu'on fait a=a.toString(), on écrase l'ancien pour la nouvelle valeur j'aurais comprendre, ce qui fait que b pointe sur NULL car l'ancien objet est complètement détruit, donc b devient comme une variable non instancié.
    Dans toutes les circonstances les deux points ne sont pas respectés par JavaScript. Et comme j'ai dis que l'opérateur de concaténation en Java par exemple à été bien défini pour prendre les en 2e opérandes les objet de type primitifs, qu'il soit définis avec les type primitif en soi ou les class représentant les types primitifs et ça s’arrête là. PAS DE CONVERSION IMPLICITE

    Benjamin C. Pierce n'est pas un envoyé de Dieu, c'est son avis et ça s’arrête là, il y a pas un illuminé en programmation pour orienter les avis du monde.

    Dans tout ça si le langage dont les concepteurs n'ont pas su fortifier le concept de type pour me m'aider moi développeur a éviter les bug d'ordre type sans que je sois obligé à faire des logs partout dans mon code mais il ne m'assure pas que les erreurs de types seront signalés que ça soit en compilation ou interprétation, alors il est faiblement typé. Même si vous criez mille fois qu'il ne l'est pas.

    Je continuerais à codé pour JavaScript mais dans ma conscience c'est un mal nécessaire.

  4. #124
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    4 069
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 4 069
    Points : 8 944
    Points
    8 944

    Par défaut

    Salut la lune
    les expressions que je donnais à propos de C++, Java et autres sont à prendre sur le FOND pas sur la forme.
    je ne parlais pas de code je donnais un principe :
    en C++ on peu définir un opérateur + qui prends un String et un Integer pour retourner une String.
    et on peut faire cela quelque soit le type des objets. passé en paramètres.

    Javascript ne se donne aucun droit sur l'interprétation sémantique des paramètres. l'opérateur + à une signature définie en C++ et il l'utilise. que cette signature soit celle que vous attendez ou pas ne change rien. il n'y a aucune magie aucune transformation il y a juste l'application d'une méthode simple.
    la définition de cette méthode prête à discussion. pourquoi pas mais ça reste tout comme en C++ l'application d'une méthode conformément à sa signature.

    quant au NaN si je fais une méthode C++ sinus qui prends en paramètre une référence à tout type d'objet
    et qui retourne NULL si le paramètre ne peut être utilisé pour faire un sinus
    C++ n'est pas pour autant faiblement typé.
    Pourquoi la définition de la même fonction en JS ferais de JS un langage faiblement typé ?
    Je ne dis pas que c'est une bonne chose. je dis que c'argument ne peu pas pour java impliqué qu'il est fortement type et impliquer pour javascript le contraire. ce n'est pas un argument valable.

    si je remplace la lib standard de JS par la mienne qui comme en C++ vérifie le Type et produit une exception
    JS sera-t-il pour autant fortement typé ?
    pour moi non dans les deux cas. ce n'est pas la signature des opérateurs ni des méthodes qui permettent de dire qu'un langage est faiblement type.

    Tu dis détecter un erreur c'est lever un exception une erreur un warning. crois tu qu'avant l'introduction des exception dans les langage on ne gérait pas les erreurs ?
    on trouve encore des fonctions dans des langage pourtant strict qui retourne un int indiquant comment s'est déroulé l'exécution.
    la encore je ne dis pas que c'est la meilleurs façon de faire. mais elle existe et elle permet de détecter les erreurs.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    if (0 < read(fs, buff) {
      ...
    } else {
      ...
    }
    ce n'est donc qu'un choix dans la façon de programmer. et je comprends qu'on préfère gérer des exceptions plutôt que de tester des valeurs de codes retournés.

    détrompe toi écrire un compilateur JS est autrement plus complexe que d'écrire un compilateur C++. car justement c'est l'analyse syntaxique et sémantique qui permets d'inférer les types. alors qu'un C++ c'est le développeur qui le fait. et justement non JS ne se moque pas des types. il les respectes.
    quand à ce que tout le monde prends pour de la conversion de type il ne s'agit que d'appel de méthodes.

    enfin dans mon exemple
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    Object a = new Integer(5);
    Integer b = a;
    typeof a; // Integer
    log(b); //5
    a.toString(); // Modifie la zone mémoire alloué par new Integer(5); pour en faire une string
    String c = a;
    typeof a; // String
    log(b); //null
    log(c); //"5"
    je parle de langage capable de changer le type d'un Objet. je ne parle pas de a b ou c dans ce code je parle de la zone mémoire créé par new Integer(5); dans certain langage l'appel a.toString(); converti la zone mémoire référencé par a et b en une String. mais comme b est de type Integer, le runtime casse la référence b vers cette zone. ni a ni be ni C n'ont changé de type pourtant la zone mémoire référencé par a est devenue une string
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    Object a = new Integer(5);
    //on vérifie le type de l'objet référencé par a c'est un Integer
    typeof a; // Integer
    log(b); //5
    a.toString(); // Modifie la zone mémoire alloué par new Integer(5); pour en faire une string
    //on vérifie le type de l'objet référencé par a c'est une String
    typeof a; // String
    log(c); //"5"
    l'objet à changé de type.
    Je ne discute pas de l'utilité de tel langages (s'ils existe c'est pour répondre à des besoins)
    Je dis juste que de mon point de vu personnel il ne fait aucun doute que de tel langages sont faiblement typés
    Alors qu'un compilateur à la Java ne trouverait rien à redire.
    de mon point de vu la vérification syntaxique n'est donc pas suffisante pour conclure sur le fait que le langage est fortement typé ou pas car j'ai deux langage qui respecte cette règle de lever une exception ou une erreur sur l'analyse syntaxique du code alors que l'un est fortement typé et l'autre non.

    je suis entièrement d'accord pour dire que
    Benjamin C. Pierce n'est pas un envoyé de Dieu
    mais ce n'est pas parce que tu as choisi 1 définition parmi des centaines pour dire ce qu'un langage faiblement typé que c'est une vérité absolue. B. C. Pierce n'est qu'un parmi d'autre qui c'est penché sur ce problème. et il a trouvé beaucoup trop de définitions pour conclure.

    cela n'empêche pas de faire un choix. il suffit d'être conscient que c'est un choix.

    Je tiens à rappeler ici que je ne conteste pas que JS soit faiblement typé. de mon point de vu perso c'est le cas.
    ce que je conteste ce sont les arguments avancés.
    Non JS ne fais pas n'importe quoi. Non Js ne converti pas les objets au petit bonheur la chance, non JS ne ne moque pas des type.

    Je conteste les arguments qui veulent prouver que JS est faiblement typé en se basant sur des assertions qui en C++ Java ou autre donne le contraire.
    Pour moi une telle expression ne prouve rien. c'est le B.A.BA de la logique
    si assertion A alors faiblement type
    assertion A et JS alors faiblement typé
    assertion A et Java alors fortement typé

    A+JYT

  5. #125
    Futur Membre du Club
    Profil pro
    Inscrit en
    février 2009
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2009
    Messages : 8
    Points : 5
    Points
    5

    Par défaut Pinaillage

    Quitte à faire de la sémantique terminologique, autant le faire correctement.

    1. Javascript n'est pas un langage orienté objet.

    2. Tout n'est pas objet dans Javascript, contrairement à Ruby, par exemple, ou même les valeurs nil, true et false sont des objets.

  6. #126
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    juillet 2017
    Messages
    70
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 25
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : juillet 2017
    Messages : 70
    Points : 113
    Points
    113

    Par défaut

    JavaScript natif est un langage un peu méconnu au niveau du typage. Il est très compliqué de gérer un typage en JS qui se gère automatiquement d'ailleurs, ça va vite de faire du code dégueulasse.

    L'avenir est dans le TypeScript maintenant, qui permet de gérer tout un tas de types de manière beaucoup plus efficace. Et surtout TypeScript est beaucoup plus lisible à ce niveau là et demande moins de connaissances pour des débutants.

    Pareil en JavaScript, les classes n'existent pas, on parle d'un langage orienté prototype. Mais encore une fois, c'est tellement une galère à gérer correctement que honnêtement, autant pas s’embêter avec ça.

    Exemple de classe en TypeScript :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    class Lion extends Animal {
      sex: string;
     
      constructor(name: string, sex: string) {
        super(name);
     
        this.sex = sex;
      }
     
      shout(): string {
        return "Rooooaarrr!"
      }
    }
    La même en VanillaJs (Javascript natif)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    var __extends = (this && this.__extends) || (function () {
        var extendStatics = Object.setPrototypeOf ||
            ({ __proto__: [] } instanceof Array && function (d, b) { d.__proto__ = b; }) ||
            function (d, b) { for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p]; };
        return function (d, b) {
            extendStatics(d, b);
            function __() { this.constructor = d; }
            d.prototype = b === null ? Object.create(b) : (__.prototype = b.prototype, new __());
        };
    })();
    var Lion = /** @class */ (function (_super) {
        __extends(Lion, _super);
        function Lion(name, sex) {
            var _this = _super.call(this, name) || this;
            _this.sex = sex;
            return _this;
        }
        Lion.prototype.shout = function () {
            return "Rooooaarrr!";
        };
        return Lion;
    }(Animal));
    Si vous voulez en savoir plus sur les différents types en TypeScript, vous pouvez aller voir cet article

    Si vous voulez continuer à vous embêter avec du JS natif, je vous souhaite bon courage
    (Si vous avez une TMA à faire sur du Js natif, je vous souhait encore plus de courage )

  7. #127
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 196
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 196
    Points : 9 313
    Points
    9 313

    Par défaut

    @pterrat: le code ci-dessous est du JS standard (norme ES2015), qui fonctionne sans transpilation nécessaire sur 90% des navigateurs. Et babel-preset-env s'occupe des 10% restants sans problèmes.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    class Animal {
    	constructor(name){
    		this.name = name;
        }
    }
     
     
    class Lion extends Animal {
      constructor(name, sex) {
        super(name);
     
        this.sex = sex;
      }
     
      shout() {
        return "Rooooaarrr!"
      }
    }
     
     
    const simba = new Lion()
    simba.shout()
    Typescript se calque volontairement sur les évolutions du langage JavaScript pour maintenir son interopérabilité (on peut renommer un *.js en *.ts et ça doit compiler). On peut vanter les syntaxes spécifiques TypeScript comme les enums ou le JSX, mais pour ce qui est des classes, ça fait partie du standard
    One Web to rule them all

  8. #128
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    juillet 2017
    Messages
    70
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 25
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : juillet 2017
    Messages : 70
    Points : 113
    Points
    113

    Par défaut

    Tu as raison. Il me semble de mémoire que les classes de la norme ES2015 ne sont pas prises en compte par IE.

  9. #129
    Candidat au Club
    Homme Profil pro
    Inscrit en
    avril 2013
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : avril 2013
    Messages : 1
    Points : 3
    Points
    3

    Par défaut

    Pour moi, cet article est proche du grand n'importe quoi. Des règles générales :

    - un langage fortement typé n'admet pas le typage dynamique. Point !
    - un langage fortement typé refuse de s'éxécuter s'il y a une erreur de type : il faut d'abord rendre les types (paramètre, affectations) compatibles pour exécuter le code. C'est une règle générale, pas absolue.
    - un langage fortement typé peut être statiquement analysé : dès qu'un langage n'est pas statiquement analysable, il n'est pas fortement typé. C'est ce qui permet les assistants profonds et la détection d'erreur lors de la frappe du code.
    - un langage fortement typé objet respecte la hiérarchie des classes : il applique le principe de Liskov (principe de la programmation objet)
    - non JS n'est pas un langage objet : il permet seulement de simuler des classes, mais n'a aucunes des qualités requises pour pouvoir être considéré comme fortement typé : ni encapsulation, ni héritage, ni polymorphisme, ni généricité, ni interface (contrat), ni contraites de types, ni abstractions, rien... C'est un langage de script qui permet seulement de singer les vrais langages objets !

  10. #130
    Membre émérite Avatar de psychadelic
    Profil pro
    Inscrit en
    mai 2010
    Messages
    1 494
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2010
    Messages : 1 494
    Points : 2 985
    Points
    2 985

    Par défaut

    @Gabbby Titrer que JavaScript est un langage fortement était juste un titre provocateur, ainsi que l'argumentation qui en a suivi.

    Et tu n'es pas le seul à avoir pris la mouche pour réagir sur le sujet proposé.

    En fait, je suis relativement d'accord avec ce qu tu a écrit, jusqu'a
    - non JS n'est pas un langage objet :...
    je te renvois à l'article de sylvainpv Onze idées fausses sur l'héritage en JavaScript
    mais il doit y avoir d'autres, car que tu le veuilles ou non JavaScrit est un langage Objet, mais qui n'utilise pas un mécanisme par classes mais par prototypes.
    Ce qui est presque normal puisque c'est un langage interprété.


    C'est un langage de script qui permet seulement de singer les vrais langages objets !
    C'est un peu violent non ?
    Voir même un peu méprisant envers la communauté de développeurs travaillant sous JavaScript sous l'une ou l'autre de ses multiples faces : NodeJS, Angular, Electron..
    et de ses incroyables réalisations, comme Visual Studio Code de Microsoft, NetFlix (ils ont laissé tomber Java en 2015) ...

    D'ailleurs, cela ne t'étonne pas que le Langage JavaScript soit l'un des plus utilisé sous GitHub, stackOverflow ?
    Ne vas pas me faire croire que tous ces contributeurs sont des écervelés !

    https://madnight.github.io/githut/#/...equests/2017/4
    https://insights.stackoverflow.com/s...017#technology
    «La pluralité des voix n'est pas une preuve, pour les vérités malaisées à découvrir, tant il est bien plus vraisemblable qu'un homme seul les ait rencontrées que tout un peuple.» [ René Descartes ] - Discours de la méthode

  11. #131
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 855
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 855
    Points : 39 548
    Points
    39 548

    Par défaut

    Citation Envoyé par Gabbby Voir le message
    - un langage fortement typé objet respecte la hiérarchie des classes : il applique le principe de Liskov (principe de la programmation objet)
    Mais un langage fortement typé n'est pas forcément un langage orienté objet (par exemple Haskell est un langage purement fonctionnel, sans aucune notion de POO, et il est très fortement typé). Et de toute façon, le respect du principe de Liskov ne dépend pas du langage, mais du programmeur... Tu peux violer ce principe en Java, en C#, en C++ ou n'importe quel autre langage objet.

    Bref... De toute façon je pense qu'avec l'arrivée de WebAssembly, les jours de Javascript sont comptés. Il va survivre encore un bon moment, et il aura sans doute toujours ses fans, mais je pense qu'à terme les gens utiliseront d'autres langages plus robustes, compilés en WebAssembly, pour le développement front. Voir démo de Blazor (prototype de framework SPA basé sur C# et WebAssembly) ici (à 31m45)

  12. #132
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 196
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 196
    Points : 9 313
    Points
    9 313

    Par défaut

    @tomlev: pour arriver à utiliser des langages haut niveau qui compilent en WASM, il faudra encore du temps. Il n'a pas vraiment été pensé en ce sens, et beaucoup de fonctionnalités manquent encore. A court terme, transpiler directement en JS me paraît plus judicieux, comme le font déjà de nombreux langages: TypeScript, Kotlin, Haxe etc... Et on peut toujours utiliser WASM pour des tâches bien spécifiques, comme certains algorithmes ou des moteurs graphiques.

    Si les ingénieurs derrière WASM n'arrêtent pas de répéter qu'il ne va pas remplacer JS, c'est parce qu'en taille de bundle JS aura toujours l'avantage (la js1k le prouve chaque année), et que pour un usage web classique, c'est ce qui compte le plus. WASM ne va pas remplacer JS, mais JS va probablement rejoindre WASM dans le rang des langages cible de compilation. Dans tous les cas, les développeurs auront plus de choix dans les langages à disposition, c'est ce qu'il faut retenir.
    One Web to rule them all

  13. #133
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 645
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 645
    Points : 8 738
    Points
    8 738

    Par défaut

    Citation Envoyé par SylvainPV Voir le message
    @tomlev: pour arriver à utiliser des langages haut niveau qui compilent en WASM, il faudra encore du temps. Il n'a pas vraiment été pensé en ce sens, et beaucoup de fonctionnalités manquent encore. A court terme, transpiler directement en JS me paraît plus judicieux, comme le font déjà de nombreux langages: TypeScript, Kotlin, Haxe etc... Et on peut toujours utiliser WASM pour des tâches bien spécifiques, comme certains algorithmes ou des moteurs graphiques.
    Utiliser un langage de haut niveau est tout a fait possible, ça marche déjà plutôt bien par exemple avec C++ et Rust. Le principe de base, c'est que si on peut faire du bas niveau, on peut en principe faire du haut niveau vu que le haut niveau repose sur l'utilisation cadrée de concepts de bas niveau. L'inverse est plus difficile, même si ça n'est pas complètement impossible comme l'a montré asm.js.
    Actuellement, le seul souci est pour les langages avec leur propre garbage collector qui ne peuvent pas partager directement leur objets avec JavaScript car les deux Garbage collector pourraient entrer en conflit. Mais il est prévu à l'avenir de permettre a WASM d'interagir directement avec le Garbage Collector du moteur JavaScript pour résoudre ce problème.

    Citation Envoyé par SylvainPV Voir le message
    Si les ingénieurs derrière WASM n'arrêtent pas de répéter qu'il ne va pas remplacer JS, c'est parce qu'en taille de bundle JS aura toujours l'avantage (la js1k le prouve chaque année), et que pour un usage web classique, c'est ce qui compte le plus. WASM ne va pas remplacer JS, mais JS va probablement rejoindre WASM dans le rang des langages cible de compilation. Dans tous les cas, les développeurs auront plus de choix dans les langages à disposition, c'est ce qu'il faut retenir.
    Des concours du genre de la js1k ne sont pas l’apanage du JavaScript, il y en a avec tout type de technologie.
    De plus on ne peut pas comparer du code géré automatiquement et écrit à la main. Le code compilé a partir qu'autres langages est rarement optimal en taille.
    Enfin, le WASM a été pensé pour être efficace en terme de taille et de performance. Son avenir en tant que cible de compilation me semble clair.

    Si les promoteur de WASM annoncent qu'il ne va pas remplacer le JS partout, c'est surtout que le JS reste le seul langage utilisable directement dans le navigateur sans compilation, ce qui fait qu'il restera un choix pour son domaine original : le script d'interface simple.

  14. #134
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 196
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 196
    Points : 9 313
    Points
    9 313

    Par défaut

    Si tu considères que C++ est un langage haut niveau, oui évidemment c'est possible, vu que C/C++ sont justement les langages choisis pour le MVP de WebAssembly. Je pensais plus à des langages comme Java, Scala, Kotlin... Comme tu le mentionnes, le garbage collector est un problème, parmi d'autres. Il y a tout un tas de compilateurs expérimentaux mais le code produit est trop lourd et soumis à plein de contraintes diverses. C'est pour ça que je dis qu'il faudra encore du temps.

    On est d'accord qu'on ne peut pas comparer du code généré automatiquement et écrit à la main, il n'empêche que JS reste très optimal même en cible de compilation. Sa syntaxe permissive permet d'avoir des minifiers très efficaces. Dans des concours comme le js1k, le plus gros des gains en taille est fait automatiquement par des packers spécialisés, même si les golfers doivent comprendre comment ils fonctionnent et retravailler leur code pour en tirer le maximum.

    Je dis que JS va devenir un langage cible de compilation, mais en vérité il l'est déjà. Des centaines de langages compilent vers JS et même quand on code en JS vanilla, aujourd'hui on passe par tout un process de build babel/uglify/prepack/trucbidule et le code en sortie ne ressemble plus vraiment à celui d'origine. Tous ces compilos et outils ne vont pas migrer vers WASM, même quand le support et les fonctionnalités seront là, simplement parce que le code en sortie sera plus lourd que la version JS minifié, et que le gain de perf ne vaudra pas le coup par rapport à l'augmentation de taille. Pour un usage web classique, je reprécise encore. On verra si le futur me donne raison ou pas.
    One Web to rule them all

  15. #135
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 645
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 645
    Points : 8 738
    Points
    8 738

    Par défaut

    Citation Envoyé par SylvainPV Voir le message
    Si tu considères que C++ est un langage haut niveau, oui évidemment c'est possible, vu que C/C++ sont justement les langages choisis pour le MVP de WebAssembly. Je pensais plus à des langages comme Java, Scala, Kotlin... Comme tu le mentionnes, le garbage collector est un problème, parmi d'autres.
    Ok tu veux plutôt parler des langages avec un gros Runtime que des langages de haut niveau en général.
    Dans ce cas là, c'est vrai qu'il faut inclure le Runtime dans le WebAssembly si on veut les faire marcher avec l'infrastructure existante. Donc effet, c'est plus lourd, il n'y a pas de miracle. Mais s'il veulent faire un backend WASM officiel, il y a fort a parier qu'il arriveront à produire un Runtime allégé.

    Citation Envoyé par SylvainPV Voir le message
    Je dis que JS va devenir un langage cible de compilation, mais en vérité il l'est déjà. Des centaines de langages compilent vers JS et même quand on code en JS vanilla, aujourd'hui on passe par tout un process de build babel/uglify/prepack/trucbidule et le code en sortie ne ressemble plus vraiment à celui d'origine.
    En effet, le JavaScript est actuellement la cible de compilation de toutes les technologies web qui ciblent le client. Et le but de WebAssembly est justement de remplacer JavaScript dans cet cet usage précis. Il faut voir que WASM a été étudié spécialement pour cela. C'est un format binaire qui il vise particulièrement à être rapide à télécharger et compiler.

    Citation Envoyé par SylvainPV Voir le message
    Tous ces compilos et outils ne vont pas migrer vers WASM, même quand le support et les fonctionnalités seront là, simplement parce que le code en sortie sera plus lourd que la version JS minifié, et que le gain de perf ne vaudra pas le coup par rapport à l'augmentation de taille. Pour un usage web classique, je reprécise encore. On verra si le futur me donne raison ou pas.
    Je ne doute pas que certains outils ne migreront pas, mais ça sera surtout par ce que c'est trop complexe de revoir toute leur infrastructure pour le WASM.

    Par contre rien ne semble indiquer que JavaScript sera forcément plus léger que WASM. C'est vrai que JavaScript se minimise très bien, mais WASM est un format binaire conçu spécifiquement pour être léger. Les tests réalisé sur emscriptem, indiquent que WASM est 10 à 20% plus léger que du JavaScript (les deux étant minimisés et compressés).

    Il faut aussi voir que la taille n'est pas le seul élément a rentrer en compte. WebAssembly se compile également bien plus vite avec des performances potentiellement meilleures.

  16. #136
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 196
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 196
    Points : 9 313
    Points
    9 313

    Par défaut

    Citation Envoyé par Uther Voir le message
    le but de WebAssembly est justement de remplacer JavaScript dans cet cet usage précis. Il faut voir que WASM a été étudié spécialement pour cela.
    La FAQ du site officiel affirme pourtant tout le contraire: http://webassembly.org/docs/faq/#is-...ace-javascript

    C'est également ce que j'entends de la bouche de tous les gens qui travaillent sur WASM depuis des années, Brendan Eich en tête. WASM ne remplacera pas JavaScript, il sera complémentaire dans son usage.

    Je veux bien voir à quels tests Emscripten tu fais référence pour le gain de 10 à 20%, pour voir si ça correspond vraiment à un usage web classique ou si c'est juste une démo technique genre suite de Fibonacci.
    One Web to rule them all

  17. #137
    Membre expérimenté

    Homme Profil pro
    Développeur multimédia
    Inscrit en
    juillet 2004
    Messages
    978
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur multimédia
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2004
    Messages : 978
    Points : 1 708
    Points
    1 708
    Billets dans le blog
    1

    Par défaut

    J'ai testé cette technologie WebAssembly, elle semble être adapté a une personne venu du software vers du web sans connaissance réel en javascript, elle ne remplacera pas javascript d'ailleurs cette techno est limité a ça dans une "VM" mais en utilisant l'existant de javascript donc on est dans le même contexte et les risques sont les mêmes que le langage natif. Les nouvelles implémentations html5 ne sont pas toutes gérés en totalité, impossibilités d'utiliser les sockets..., une ressource externe type DLL's (...unsafe), ce limite a des appels web services/api ...
    J'y ai cru un petit moment, on est loin d'égalé JS ... l’intérêt peut être du fait qu'il fait partie du monde du .NET sa portabilité j'ai pas tout exploré, il ne s'impose pas si on a un minimum de connaissance JS l'intérêt peut être son côté POO et plus facile a maintenir et à gérer pour C#*JAVA C++...

  18. #138
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 645
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 645
    Points : 8 738
    Points
    8 738

    Par défaut

    Citation Envoyé par SylvainPV Voir le message
    La FAQ du site officiel affirme pourtant tout le contraire: http://webassembly.org/docs/faq/#is-...ace-javascript

    C'est également ce que j'entends de la bouche de tous les gens qui travaillent sur WASM depuis des années, Brendan Eich en tête. WASM ne remplacera pas JavaScript, il sera complémentaire dans son usage.
    Ça n'a absolument rien de contradictoire avec ce que j'ai dit. Je n'ai jamais prétendu que WebAssembly vise à remplacer JavaScript en tant que langage de programmation. JavaScript restera le seul langage de script directement intégré à tous les navigateurs et donc un choix privilégié pour les développements client légers.

    Par contre, WebAssembly a spécifiquement été conçu pour être une technologie plus adaptée que JavaScript dans le rôle de cible de compilation pour les langages tiers.

    Citation Envoyé par SylvainPV Voir le message
    Je veux bien voir à quels tests Emscripten tu fais référence pour le gain de 10 à 20%, pour voir si ça correspond vraiment à un usage web classique ou si c'est juste une démo technique genre suite de Fibonacci.
    J'avais vu cette estimation là : https://hacks.mozilla.org/2017/03/wh...r-than-asm-js/
    Ce n'est pas des simples démos techniques, mais pas non plus un usage web classique à base de manipulation du DOM, vu que WebAssembly n'est pas encore capable de faire ça directement. Il n'est pas impossible que Javacript puisse être légèrement plus léger en fonction des cas, mais il faut voir que l'écart ne sera probablement pas colossal, dans un sens comme dans l'autre.
    Quand la technologie sera bien stabilisée, il sera généralement préférable d'utiliser une technologie de bytecode prévue pour ça avec de meilleures performances générales et des outils adaptés qu'un hack à base de transpilation.

    Citation Envoyé par headmax Voir le message
    elle ne remplacera pas javascript d'ailleurs cette techno est limité a ça dans une "VM" mais en utilisant l'existant de javascript donc on est dans le même contexte et les risques sont les mêmes que le langage natif.
    Je suis pas sur d'avoir bien compris ce que vous voulez dire : cette phrase ne semble plutôt contradictoire.

    Pour ce qui est des interactions avec le navigateur et la machine, WebAssembly sera en effet limité au API Web de JavaScript, accéder directement aux ressources de la machines (socket, bibliothèques systèmes,...) serait une terrible faille de sécurité pour un navigateur.
    Donc au final, les risques de sécurité seront exactement les mêmes que pour le JavaScript.

    Citation Envoyé par headmax Voir le message
    Les nouvelles implémentations html5 ne sont pas toutes gérés en totalité
    Le WebAssembly est loin d'être terminé. En effet, dans les implémentations actuelles, il lui manque encore l'accès à pas mal des API Web de JavaScript (notamment DOM). Mais à terme, WebAssembly devrait avoir accès à toutes.

  19. #139
    Membre expérimenté

    Homme Profil pro
    Développeur multimédia
    Inscrit en
    juillet 2004
    Messages
    978
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur multimédia
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2004
    Messages : 978
    Points : 1 708
    Points
    1 708
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par Uther
    Je suis pas sur d'avoir bien compris ce que vous voulez dire : cette phrase ne semble plutôt contradictoire.
    En effet le terme "VM" que j'ai m'y entre me semble pas approprié, n'ayant pas assez de recule sur cette techno voici un lien bien plus explicite concernant ce sujet https://floooh.github.io/2017/06/09/...mystified.html

  20. #140
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 196
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 196
    Points : 9 313
    Points
    9 313

    Par défaut

    Les configurations évoquées dans la FAQ stipulent que JS sera toujours utilisé en complément de WASM. Je pense notamment que la configuration 3 ("Mostly HTML/CSS/JavaScript app with a few high-performance WebAssembly modules") sera le cas le plus courant pour l'usage web classique. Le canvas de la config 2 sera bien joli pour les démos techniques, mais snobber le DOM n'est pas envisageable pour toutes les contraintes SEO/accessibilité/amélioration progressive...

    Alors si JS reste incontournable, pourquoi ça ne serait pas une cible de compilation ? Ça l'est déjà actuellement comme expliqué précédemment, et si en plus le WASM rend obligatoire l'usage d'un compilateur, alors il n'y a aucune raison de s'en priver. Parions-même que dans les langages alternatifs, des frameworks viendront gérer à la place du développeur ce mélange de JS/WASM en sortie. Je ne m'avance pas à grand chose en disant cela, puisque c'est déjà ce que font les premiers frameworks expérimentaux là-dessus : https://github.com/aspnet/blazor ; https://github.com/DenisKolodin/yew
    One Web to rule them all

Discussions similaires

  1. Réponses: 31
    Dernier message: 21/02/2018, 18h15
  2. Réponses: 9
    Dernier message: 27/02/2010, 21h15
  3. Réponses: 2
    Dernier message: 15/01/2010, 17h52
  4. Réponses: 2
    Dernier message: 15/01/2010, 17h52
  5. Réponses: 1
    Dernier message: 05/10/2007, 17h56

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo