Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

TypeScript Discussion :

TypeScript 1.5 en production


Sujet :

TypeScript

  1. #21
    Membre éclairé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    239
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 239
    Points : 653
    Points
    653
    Par défaut
    Citation Envoyé par SylvainPV Voir le message
    En pratique, je ne vois pas comment utiliser conjointement TypeScript et ObjectModel. Typer à la fois statiquement et dynamiquement n'a pas de sens, on combine les inconvénients et on perd les avantages.
    Pourquoi pas ?

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    declare var Model;
    interface Person {
    	id: number;
    	name: string;
    }
    let PersonModel = new Model({
    	id: Number,
    	name: String
    });
    let p: Person = new PersonModel(JSON.parse('...')); // contrôle par ObjectModel
    console.log(p.name); // assistance à la saisie sur "p."
    Le code généré :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    var PersonModel = new Model({
        id: Number,
        name: String
    });
    var p = new PersonModel(JSON.parse('...'));
    console.log(p.name);
    La double définition n'est pas DRY, c'est vrai. Mais dans un projet TS, ObjectModel peut jouer son rôle de validateur pour des données venant de l'extérieur du programme.

  2. #22
    Membre éclairé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    239
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 239
    Points : 653
    Points
    653
    Par défaut
    En fait, dans le cadre d'un projet TS, une version light de ObjectModel pourrait ne vérifier le typage qu'une seule fois (à l'import d'un objet JSON par exemple).
    Quelque chose comme ça :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    declare var LightModel;
    interface Person {
    	id: number;
    	name: string;
    }
    let personValidator = LightModel.makeValidator({
    	id: Number,
    	name: String
    });
    let p: Person = JSON.parse('...');
    personValidator(p); // contrôle par ObjectModel
    console.log(p.name); // assistance à la saisie sur "p."

  3. #23
    Rédacteur/Modérateur

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

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 260
    Points : 9 544
    Points
    9 544
    Par défaut
    Dans ce cas on perd tout l'intérêt de la flexibilité du typage dynamique. Quand je dis qu'on combine les inconvénients et qu'on perd les avantages, j'entends par là :
    - on perd l'avantage du typage statique d'être performant et de valider à la compilation sans avoir recours à l'inférence de types
    - on perd l'avantage du typage dynamique de pouvoir muter les types et les conditions de validation pendant l'exécution
    - on doit combiner les deux déclarations de types, qui sont fondamentalement différentes (ton exemple Person est très simpliste ici, il ne reflète pas un cas réel)

    L'intersection de ces deux approches est bien trop limitée, ça se réduit à ta dernière proposition qui se résume à une fonction pour valider un modèle manuellement et ponctuellement. Ce n'est pas du tout l'optique de ObjectModel.
    One Web to rule them all

  4. #24
    Membre éclairé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    239
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 239
    Points : 653
    Points
    653
    Par défaut
    Citation Envoyé par SylvainPV Voir le message
    - on perd l'avantage du typage dynamique de pouvoir muter les types et les conditions de validation pendant l'exécution
    Les avantages du typage dynamique ne sont pas perdus avec TypeScript. Pourrait-on voir un exemple concret ?

    Citation Envoyé par SylvainPV Voir le message
    L'intersection de ces deux approches est bien trop limitée, ça se réduit à ta dernière proposition qui se résume à une fonction pour valider un modèle manuellement et ponctuellement. Ce n'est pas du tout l'optique de ObjectModel.
    OK mais la validation d'une arborescence JSON est en tout cas un besoin récurrent, en TS autant qu'en JS.

  5. #25
    Rédacteur/Modérateur

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

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 260
    Points : 9 544
    Points
    9 544
    Par défaut
    Pour reprendre ton exemple du modèle Person, imaginons que le modèle comporte un champ age: number et que lorsque l'application est dans un certain état, toutes les instances de Person doivent désormais être majeures pour être considérées valides. Avec un typage statique, on peut passer par une classe héritée AdultPerson par exemple, garder une référence à toutes les instances de Person et essayer de les caster en AdultPerson. C'est faisable bien que quelque peu fastidieux, mais ça ne nous donne pas l'assurance que ce sont des AdultPerson que l'on manipule dans les méthodes utilisant initialement des Person. Tandis qu'avec ObjectModel, on peut modifier à l'exécution le type lui-même :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    Person.assert(function(p){ return p.age >= 18; });
    Ici c'est une assertion donc on pourrait dire que ça sort du cadre du typage, mais je pourrais trouver un autre exemple où les ID deviennent des String et non plus des nombres.

    Si tu parles du typage dynamique en JavaScript et non du typage fort offert par ObjectModel, il n'y aura pas d'exceptions levées, mais le principe est le même: on peut avoir une collection de personnes et décider tout à coup qu'une des personnes dans la collection aura un âge de type Date au lieu de Number. Ce sera permis par JavaScript mais interdit par TypeScript sans un cast approprié.

    Les défenseurs du statique argumentent souvent en critiquant le côté glissant de cette approche. D'après eux, il vaut mieux garder des structures de données immuables et des hiérarchies "solides" de classes. Mais c'est cette même rigidité qui est décriée par les défenseurs du dynamique qui ne supportent plus d'avoir des hiérarchies immenses et impossibles à maintenir, avec des modèles de données imprimés sur feuilles A3.
    One Web to rule them all

  6. #26
    Membre éclairé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    239
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 239
    Points : 653
    Points
    653
    Par défaut
    Citation Envoyé par SylvainPV Voir le message
    Ici c'est une assertion donc on pourrait dire que ça sort du cadre du typage, mais je pourrais trouver un autre exemple où les ID deviennent des String et non plus des nombres.
    Oublions les classes car elles appartiennent à ES6 et non à TypeScript. Prenons les identifiants number vs string. Admettons que nous ayons deux fonctions qui prennent presque le même type d'objet en paramètre. Nous pouvons procéder ainsi :

    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
    interface Person {
    	id: number;
    	name: string;
    }
    interface PersonVariant {
    	id: string;
    	name: string;
    }
    function f1(p: Person) {
    	p.id; // autocompletion: id is a number
    }
    function f2(p: PersonVariant) {
    	p.id; // autocompletion: id is a string
    }
    let p: any = {
    	id: 12,
    	name: 'John'
    }; // nous utilisons le type "any" afin d'annuler la définition par inférence
    f1(p);
    p.id = '12';
    f2(p);
    Je l'ai écrit plus haut : TypeScript est un mécanisme comparable à JSDoc, en beaucoup plus puissant et réutilisable. Il ne contrôle que le contrat que nous lui donnons à valider. Et l'outil le plus souple pour définir ce contrat, c'est l'interface.

  7. #27
    Rédacteur/Modérateur

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

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 260
    Points : 9 544
    Points
    9 544
    Par défaut
    Interfaces, classes, objets de définition de modèles, ça ne change rien au problème du typage: les déclaations statiques sont immuables donc n'ont pas la souplesse du typage dynamique. C'est ce qui t'oblige ici à déclarer 2 interfaces et 2 déclinaisons de méthodes, puis passer par le type Any. On ne peut pas créer dynamiquement de nouvelles interfaces, ni changer les règles du contrat de typage à l'exécution. On peut voir ça comme une bonne ou une mauvaise chose, ce sont juste des approches différentes.

    Au final, j'ai quand même réussi à rouvrir le débat dynamique vs statique Je vais donc copier/coller le résumé du débat de cet excellent article de Smashing Magazine, qui je pense fait le tour du sujet :
    The static programmer says: The dynamic programmer says:
    “Static typing catches bugs with the compiler and keeps you out of trouble.” “Static typing only catches some bugs, and you can’t trust the compiler to do your testing.”
    “Static languages are easier to read because they’re more explicit about what the code does.” “Dynamic languages are easier to read because you write less code.”
    “At least I know that the code compiles.” “Just because the code compiles doesn’t mean it runs.”
    “I trust the static typing to make sure my team writes good code.” “The compiler doesn’t stop you from writing bad code.”
    “Debugging an unknown object is impossible.” “Debugging overly complex object hierarchies is unbearable.”
    “Compiler bugs happen at midmorning in my office; runtime bugs happen at midnight for my customers.” “There’s no replacement for testing, and unit tests find more issues than the compiler ever could.”
    http://www.smashingmagazine.com/2013...-type-systems/

    Voilà, on devrait avoir fait le tour de l'argumentaire avec ça. Choisissez ce que vous voulez, défendez votre approche, sachez vous adapter en cas de besoin. Mais si je peux me permettre un conseil, parler de "régression mentale" n'est jamais le meilleur moyen de démarrer posément un débat
    One Web to rule them all

  8. #28
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    juillet 2013
    Messages
    1 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 205
    Points : 7 570
    Points
    7 570
    Billets dans le blog
    43
    Par défaut
    Citation Envoyé par SylvainPV Voir le message
    Mais si je peux me permettre un conseil, parler de "régression mentale" n'est jamais le meilleur moyen de démarrer posément un débat
    Pour être exact j'ai employé l'expression "Régression des mentalités" nuance. Pour la simple raison que les langages à typage dynamique correspondent plutôt aux débuts de l'informatique : L'assembleur pouvant être considéré comme non typé (ou monotype), le FORTRAN, le LISP ou le BASIC.

    L'industrie s'est rendue compte que cela posait des problèmes et c'est la raison pour laquelle on a assisté à la domination des langages à typage statique dans les décennies suivantes : PL/I, COBOL, C, Ada, C++, Java, etc.

    Néanmoins, l'arrivée de Java (ainsi que d'autres langages de la même mouvance, mais surtout Java) a causé du tort à nombres de paradigmes (typage statique et POO) en allant trop loin dans les contraintes imposées au programmeur. Contraintes que je suis le premier à le dénoncer.

    JavaScript peut être vu comme une réaction de rébellion quelque peu radicale en abandonnant pas mal d'avancées. Il faut aussi souligner que le concepteur de JavaScript ne pensait pas que le langage allait devenir aussi incontournable. C'était à la base qu'un outil pour un besoin très circonscrit (donner un peu de vie aux pages HTML très mornes de l'époque). Un script typique de l'époque du début du Web représentait une dizaine de lignes. Le formalisme de Java était clairement trop lourd. Comme ne pas avoir de typage statique explicite ne pose aucun souci de fiabilité logicielle dans ce cas, JavaScript et son typage dynamique était tout à fait approprier à ce cas d'utilisation des petits programmes.

    Maintenant, JavaScript s'est popularisé au-delà de son périmètre d'origine. Les applications Web ne sont plus des scripts d'une dizaine de lignes. Cependant, beaucoup de programmeurs JS considèrent que l'absence de typage statique est à la fois normal et souhaitable. C'est selon moi ne pas avoir conscience du cas d'utilisation premier de JavaScript qui n'est plus le même que ce que pratique les développeurs Web actuels.

    J'ai donc l'impression de "revivre" (je ne suis pas si vieux tout de même) une deuxième fois l'évolution des langages de programmation. A mesure que la taille des applications Web (et pas que) s'accroit, le besoin en typage statique se fait à nouveau sentir (inévitablement j'ai envie de dire). L'histoire n'est qu'un éternel recommencement dit-on...

    C'est en cela qu'il faut comprendre l'expression "régression des mentalités". Le typage statique doit à nouveau prouver son utilité alors qu'il a déjà été amené à le faire par le passé. Personnellement, je n'ai absolument aucun doute sur le fait que le typage statique finira par s'imposer sur le Web. Je suis juste un peu triste de constater que tant d'énergie soit dépensée pour refaire l'histoire.
    Tutoriels et FAQ TypeScript

  9. #29
    Membre éclairé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    239
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 239
    Points : 653
    Points
    653
    Par défaut
    Citation Envoyé par SylvainPV Voir le message
    Interfaces, classes, objets de définition de modèles, ça ne change rien au problème du typage: les déclaations statiques sont immuables donc n'ont pas la souplesse du typage dynamique. C'est ce qui t'oblige ici à déclarer 2 interfaces et 2 déclinaisons de méthodes, puis passer par le type Any. On ne peut pas créer dynamiquement de nouvelles interfaces, ni changer les règles du contrat de typage à l'exécution. On peut voir ça comme une bonne ou une mauvaise chose, ce sont juste des approches différentes.
    En JavaScript, on utilise JSDoc pour documenter les paramètres d'une fonction, et pourtant, il est impossible de changer dynamiquement un JSDoc. Est-ce que ça fait de JavaScript un langage au typage statique ?

    TypeScript ne rentre pas dans la catégorie "statique" au même titre que les langages de la POO classique. J'écris en TypeScript du code dynamique, avec les avantages du code dynamique, sans les inconvénients du code statique.

    En JavaScript (18 lignes) :
    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
    /**
     * @param p object {
     * 	id: number;
     * 	name: string;
     * }
     */
    function f1(p) {
      p.name; // pas d'aide à la saisie :(
    }
    /**
     * @param p object {
     * 	id: number;
     * 	name: string;
     * }
     */
    function f2(p) {
      p.name; // pas d'aide à la saisie :(
    }
    En TypeScript (10 lignes) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    interface Person {
    	id: number;
    	name: string;
    }
    function f1(p: Person) {
      p.name; // aide à la saisie :)
    }
    function f2(p: Person) {
      p.name; // aide à la saisie :)
    }
    Il n'y a pas photo.

  10. #30
    Membre éclairé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    239
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 239
    Points : 653
    Points
    653
    Par défaut
    Citation Envoyé par yahiko Voir le message
    C'est en cela qu'il faut comprendre l'expression "régression des mentalités". Le typage statique doit à nouveau prouver son utilité alors qu'il a déjà été amené à le faire par le passé. Personnellement, je n'ai absolument aucun doute sur le fait que le typage statique finira par s'imposer sur le Web. Je suis juste un peu triste de constater que tant d'énergie soit dépensée pour refaire l'histoire.
    Pour moi la régression c'est quand TS passe du temps à implémenter des mot-clés "abstract" ou "protected", ce qui montre que certains développeurs refont en TypeScript une prison mentale comparable à celles des langages de la POO classique. Le risque, c'est que des frameworks pourris suivent et entrainent dans TypeScript toute la pesanteur du monde Java, un peu comme c'est le cas en PHP. PHP est un langage dynamique plutôt fun mais les offres d'emploi sont toutes à vomir à cause des Symfony, Smarty et consorts. Pour le moment dans l'écosystème JavaScript ces développeurs sont en minorité. Croisons les doigts pour que ça continue.

  11. #31
    Rédacteur/Modérateur

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

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 260
    Points : 9 544
    Points
    9 544
    Par défaut
    @yahiko: je respecte ton avis, perso je vois des avantages et des inconvénients à chaque approche mais j'aurais tendance à croire que le test-driven development combinant validateurs de modèles, tests unitaires et tests end-to-end offre un package plus complet pour "sécuriser" le code que juste le typage statique. Si le typage statique revient à la mode, il sera probablement optionnel comme pour TypeScript. A l'avenir je pense que la question va évoluer au delà du typage, qu'on va plutôt réfléchir à qu'est-ce qu'on peut faire de mieux et de plus complet que simplement typer les variables. C'est une idée qui me traînait dans la tête avec ObjectModel quand je bossais sur les assertions et les descripteurs de propriété.

    @Tahr: Je ne sais pas ce que tu appelles "code dynamique" et "code statique", jusqu'ici on parlait uniquement du typage. Et TypeScript apporte un typage statique optionnel, c'est revendiqué et plébiscité. On ne peut pas faire de comparaison avec JSDoc qui est une convention purement informative, où l'on peut mettre n'importe quoi dedans sans casser le fonctionnement du code, même si certains IDE l'utilisent pour inférer les types (à noter qu'on peut faire de l'inférence de types sans besoin de JSDoc)
    One Web to rule them all

  12. #32
    Membre éclairé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    239
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 239
    Points : 653
    Points
    653
    Par défaut
    Citation Envoyé par SylvainPV Voir le message
    Je ne sais pas ce que tu appelles "code dynamique" et "code statique", jusqu'ici on parlait uniquement du typage. Et TypeScript apporte un typage statique optionnel, c'est revendiqué et plébiscité.
    Pardon pour l'imprécision. Je parle bien du typage. Le typage en TS est plus proche de l'inférence et du JSDoc que d'un typage comme en Java. En Java, on ne peut pas prendre un objet (correspondant à un emplacement en RAM) et subitement faire comme si le type qui lui est associé avait changé. En TypeScript, on le fait, on manipule donc les types des objets dynamiquement. Ce qui n'est pas dynamique, c'est la définition des types, et cela ne change rien au typage dynamique et modifiable des variables (les emplacements mémoire).

    Au passage, Flow est sans intérêt. Un bon IDE interprétant JSDoc fait le même travail. Chez Facebook, ils aiment se tromper de techno puis réinventer la roue.

  13. #33
    Membre expert

    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2010
    Messages
    1 761
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2010
    Messages : 1 761
    Points : 3 576
    Points
    3 576
    Par défaut
    Ce qui est un peut normal pour typescript vu que derrière ce qu'il génère c'est du JS.

  14. #34
    Membre éclairé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    239
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 239
    Points : 653
    Points
    653
    Par défaut
    L'équipe de Microsoft aurait pu créer un langage à part en supprimant les manipulations dynamiques de types. Le JavaScript serait alors généré comme le compilateur Java génère du bytecode. Au niveau du bytecode, la vérification des types n'existe plus et pourtant Java c'est du typage statique. Cette approche de compilation d'un langage au typage statique (Java) en utilisant JavaScript comme langage cible a d'ailleurs été une solution explorée par Google avec GWT.

    TypeScript se veut du JavaScript plus des informations de typage. Ce n'est pas "normal", c'est un choix de design. Et c'est pourquoi je ne suis pas trop d'accord avec SylvainPV lorsqu'il parle d' "intersection de ces deux approches" : TypeScript n'est pas un sous-ensemble de JavaScript contraint au typage statique. TS est un sur-ensemble de JavaScript. TS est du typage dynamique plus du statique optionnel. Il faut se représenter ça comme une union plutôt qu'une intersection.

  15. #35
    Rédacteur/Modérateur

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

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 260
    Points : 9 544
    Points
    9 544
    Par défaut
    C'est le mot "optionnel" qui prend toute son importance ici. Je voulais dire qu'on ne peut pas typer à la fois statiquement et dynamiquement une même variable, si on déclare une variable comme un Integer alors le typage statique nous donne la garantie qu'on travaillera toujours avec un Integer, contrairement au typage dynamique où on peut passer n'importe quoi à une fonction sans se préoccuper de sa signature. Le typage statique est une contrainte supplémentaire, dans le sens positif du mot contrainte puisqu'il est censé apporter plus de sûreté.
    One Web to rule them all

Discussions similaires

  1. [INFO] Gestion d'un environnement TEST / PRODUCTION
    Par nuke_y dans le forum Oracle
    Réponses: 19
    Dernier message: 05/08/2005, 17h14
  2. Tests Unitaires - Production de documents
    Par giviz dans le forum Test
    Réponses: 13
    Dernier message: 07/02/2005, 09h41
  3. Choix d'un sgbd open source pour de la production
    Par gueeyom dans le forum Décisions SGBD
    Réponses: 5
    Dernier message: 14/05/2004, 12h40

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