IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

JavaScript Discussion :

[Article] JavaScript est un langage fortement typé


Sujet :

JavaScript

Vue hybride

Bovino [Article] JavaScript est un... 09/08/2013, 16h32
SylvainPV Belle initiative ce recadrage... 09/08/2013, 17h33
skywaukers Alors si on part du principe... 10/08/2013, 08h22
Uther Tout dépend la définition... 10/08/2013, 09h51
sevyc64 Non ! Je fais parti de... 10/08/2013, 10h15
grim7reaper Salut, Comme tu le dis,... 10/08/2013, 10h23
FaridM En Java : String chaine... 10/08/2013, 11h20
tomlev L'argument de l'erreur de... 10/08/2013, 14h04
ternel Dans tous les langages typés,... 10/08/2013, 15h03
gl Pas vraiment. Le typage... 10/08/2013, 15h33
imikado Merci pour cet article, on en... 10/08/2013, 17h00
germinolegrand Pour ma part je dirais que... 10/08/2013, 18h07
esired J'apprécie beaucoup cet... 10/08/2013, 22h21
clementmarcotte Typé ou pas, Javascript est... 10/08/2013, 23h58
koyosama Je fais actuellement une... 11/08/2013, 01h15
stardeath totalement d'accord, je... 11/08/2013, 10h27
imikado Avec l'html5/css3/js on... 11/08/2013, 11h09
poringkiller Son nom indique aussi qu'il... 18/10/2013, 15h34
verbose Personnellement, j'ai un... 11/08/2013, 23h50
BugBlaster Bah moi je m'en moque 12/08/2013, 11h15
jfchretien Bonjour, A la lecture de... 12/08/2013, 13h18
FaridM La question n'est pas est-ce... 12/08/2013, 13h28
LSMetag Je vois quand même quelques... 12/08/2013, 13h33
yahiko Juste pour ajouter mon petit... 12/08/2013, 13h58
Loceka Non, il n'y a rien besoin de... 12/08/2013, 15h14
sjrd C'est évident, JavaScript est... 14/08/2013, 15h36
yahiko Certains points de ton post... 14/08/2013, 16h14
Darktib La définition de sjrd me... 14/08/2013, 22h13
TiranusKBX il ne doit pas y avoir... 15/08/2013, 10h16
guythom Le typage est l'essence de... 15/08/2013, 15h37
sekaijin Personnellement je ne me... 15/08/2013, 16h59
ptah35 Si je suis d'accord avec vous... 15/08/2013, 19h30
drazikh Je ne vois pas en quoi le... 16/08/2013, 12h16
sekaijin ce dernier exemple montre que... 16/08/2013, 17h51
23JFK Expliquer le typage fort par... 17/08/2013, 20h57
Invité google n'est pas le saint... 17/08/2013, 22h04
23JFK Google est quand même un gros... 17/08/2013, 22h30
tomlev Et tu crois que les gens qui... 17/08/2013, 23h09
stardeath c'est peut être que justement... 18/08/2013, 00h46
gl Au vu du reste de ton... 18/08/2013, 00h49
tomlev Pour ceux qui ne l'auraient... 18/08/2013, 02h46
sevyc64 Avant de juger ceux qui ont... 18/08/2013, 10h41
Invité on peut aussi se dire... 18/08/2013, 11h04
grim7reaper Et certains, qui ont un... 18/08/2013, 11h14
23JFK C'est un guerre de paroisse... 21/10/2013, 04h04
Invité Après la lecture de ce sujet... 19/08/2013, 11h03
ascito pour vous dire... en... 21/08/2013, 04h27
pjassemat Javascript fortement typé ??? 26/08/2013, 10h27
la.lune Dans quel langage, quelque... 05/12/2013, 18h10
Kaamo Je n'ai pas compris :koi: ... 06/12/2013, 12h25
la.lune J'ai lu tout le message de... 06/12/2013, 13h18
Kaamo join ne modifie pas tab ..... 06/12/2013, 14h14
sosolal pour moi, un langage... 22/03/2014, 16h02
la.lune Le langage C est un langage... 22/03/2014, 18h35
sosolal Je dirais que seul le... 23/03/2014, 12h28
sekaijin je trouve cela complètement... 23/03/2014, 18h14
phildepantin Pinaillage 10/09/2017, 09h04
pterrat JavaScript natif est un... 09/11/2017, 11h33
SylvainPV @pterrat: le code ci-dessous... 09/11/2017, 11h46
pterrat Tu as raison. Il me semble de... 09/11/2017, 13h32
Gabbby Pour moi, cet article est... 14/02/2018, 21h53
psychadelic @Gabbby Titrer que JavaScript... 15/02/2018, 01h30
tomlev Mais un langage fortement... 17/02/2018, 15h17
SylvainPV @tomlev: pour arriver à... 20/02/2018, 19h09
Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre extrêmement actif

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 401
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 401
    Par défaut
    Citation Envoyé par tomlev Voir le message
    Et tu crois que les gens qui ont conçu des langages à typage faible n'y ont pas aussi "réfléchi un minimum" ?
    c'est peut être que justement ils n'ont pas suffisamment réfléchi

    quand tu as affecté un entier à une variable, et que d'une manière inattendu tu te retrouves avec une string, je doute que la surprise soit de bon gout.
    je pense que tous ici, avons déjà passé quelques minutes voir heures à chercher pourquoi une variable n'avait pas la bonne valeur, et maintenant on va nous dire que c'est une bonne idée d'en plus checker si le type est bon?

    je dirai que c'est surement une blague.

  2. #2
    gl
    gl est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    Juin 2002
    Messages
    2 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Juin 2002
    Messages : 2 165
    Par défaut
    Citation Envoyé par sekaijin
    Certains voient dans le mécanisme de typage de JS un problème.
    Moi j'y vois une force.
    Au vu du reste de ton message, il me semble qu'ici tu parles plus de la distinction objet à prototype / objet à classe.
    C'est encore une notion différente du typage fort/faible ou statique/dynamique (même si dans l'esprit je trouve que ça se marie très bien avec un typage dynamique).

    Sinon +1 sur l'intérêt des prototypes et sur le fait d'utiliser les caractéristiques du langage plutôt que de se battre contre.


    Citation Envoyé par 23JFK
    Un typage fort veut dire qu'une fois que l'on a assigné un type à une variable, il n'est plus possible d'y mettre autre chose que des valeurs du type désigné lors de la définition.
    Non, ça c'est la différence entre typage statique et dynamique.


    Sinon une remarque plus globale sur la catégorisation des langages entre "faiblement typé" et "fortement typé", je n'adhère pas du tout à une telle catégorisation.
    Ce n'est pas juste deux catégories clairement distinctes (tout n'est pas blanc ou noir) mais bien un axe, une mesure relative entre langages.
    Et encore ! J'aurais même tendance à penser qu'un langage n'est pas simplement un point sur un axe typage faible-typage fort mais bien un segment sur un ensemble de critères assez distincts.

  3. #3
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    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 875
    Par défaut
    Pour ceux qui ne l'auraient pas encore lu, je vous conseille l'article Strong typing de Wikipedia, qui reprend la plupart des idées exprimées dans ce débat...

  4. #4
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2007
    Messages
    10 246
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 246
    Par défaut
    Citation Envoyé par tomlev Voir le message
    Et tu crois que les gens qui ont conçu des langages à typage faible n'y ont pas aussi "réfléchi un minimum" ?
    Citation Envoyé par stardeath Voir le message
    c'est peut être que justement ils n'ont pas suffisamment réfléchi
    Avant de juger ceux qui ont conçu les langages, posez-vous la question dans quel contexte ou été créés ces langages.

    Javascript est à la base un langage interprété, et non pas compilé. De plus interprété coté client dans des logiciels, principalement les navigateurs, dont leur vocation première n'est une quelconque compilation et vérification du code. De plus encore que c'est, c'était tout au moins au début, de l'interprétation de code à la volée, ce qui fait que, à l’exécution d'une instruction, l'environnement complet du code n'est pas forcément connu en totalité. Difficile dans ce cas de vérifier quoique ce soit sur la qualité du code.

    Bref, dans ces conditions là, le typage fort n'apporte pas forcément beaucoup d'avantages. Quant au typage faible, il se révèle plus souple et certainement moins contraignant pour les interpréteurs.

    Pour ce qui est du typage dynamique de Javascript, je n'en connais pas la raison, mais il doit bien y en avoir une, qui doit surement aussi pouvoir l'objet de débat.

    Pour ce qui est des conversion/transtypages implicites, quasiment tous les langages en font, y compris les langages à typages fort. Mais suivant la force du typage, la conversion aura plus ou moins de succès.
    Dans un code de ce type (peu importe le langage) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     i : byte =12
    j : double =12600
    k : double
     
    k = i + j
    on peut s'attendre à ce que k =12612.
    Beaucoup de langages accepterons cette opération à la compilation, y compris les langages à typage fort, malgré le fait qu'il y ait une conversion de type implicite (voire 2 suivant les langages). Certains émettrons un warning, mais rien de plus.
    A l’exécution par contre, certains feront n'importe quoi, d'autres donnerons le bon résultat. Les langages à typage fort (et surtout à typage statique) devraient, eux, et encore pas tous, renvoyer une exception pour dépassement de capacité.
    (A noter que k = j + i ne devrait poser aucun problème, quelque soit le langage, malgré, là aussi la conversion implicite)

    Tout ça pour dire que la conversion implicite n'est pas l'apanage des langages à typage faible, et tout le monde en fait tous les jours sans même s'en rendre compte.

  5. #5
    Invité
    Invité(e)
    Par défaut
    je pense que tous ici, avons déjà passé quelques minutes voir heures à chercher pourquoi une variable n'avait pas la bonne valeur,
    on peut aussi se dire pourquoi une tel erreur

    peut etre parce que la personne qui a codé avant c'est dit c'est pas grave si je fait une erreur de type elle sera détecte grâce au typage fort

  6. #6
    Membre chevronné
    Inscrit en
    Juillet 2012
    Messages
    231
    Détails du profil
    Informations forums :
    Inscription : Juillet 2012
    Messages : 231
    Par défaut
    Citation Envoyé par sevyc64 Voir le message
    Les langages à typage fort (et surtout à typage statique) devraient, eux, et encore pas tous, renvoyer une exception pour dépassement de capacité.
    (A noter que k = j + i ne devrait poser aucun problème, quelque soit le langage, malgré, là aussi la conversion implicite)
    Et certains, qui ont un typage vraiment fort, ne compilerons même pas (que ça soit j+i ou i+j).

  7. #7
    Membre extrêmement actif

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 401
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 401
    Par défaut
    Citation Envoyé par sevyc64 Voir le message
    Avant de juger ceux qui ont conçu les langages, posez-vous la question dans quel contexte ou été créés ces langages.

    Javascript est à la base un langage interprété, et non pas compilé. De plus interprété coté client dans des logiciels, principalement les navigateurs, dont leur vocation première n'est une quelconque compilation et vérification du code. De plus encore que c'est, c'était tout au moins au début, de l'interprétation de code à la volée, ce qui fait que, à l’exécution d'une instruction, l'environnement complet du code n'est pas forcément connu en totalité. Difficile dans ce cas de vérifier quoique ce soit sur la qualité du code.
    donc grosso modo, tu dis à demi mot que javascript, on ne l'utilise pas ou plus dans l'optique dans laquelle il a été créé. moi ça me va.

    par contre maintenant qu'on fait des softs un poil plus compliqués en javascript, il serait peut être temps de bazarder ces mauvaises pratiques de conceptions de langage.

    mais bon, je ne me fais pas d'illusion.

  8. #8
    Inactif  
    Profil pro
    undef
    Inscrit en
    Février 2013
    Messages
    1 001
    Détails du profil
    Informations personnelles :
    Localisation : France, Lot (Midi Pyrénées)

    Informations professionnelles :
    Activité : undef

    Informations forums :
    Inscription : Février 2013
    Messages : 1 001
    Par défaut
    Citation Envoyé par gl Voir le message
    ...
    Non, ça c'est la différence entre typage statique et dynamique.
    ...
    C'est un guerre de paroisse inutile, les deux concepts sont très proches et souvent indissociables.

  9. #9
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par 23JFK Voir le message
    Google [...] en développant le Dart, ambitionne de fournir aux développeurs de Javascript un langage fortement typé chargé de s'assurer de la bonne utilisation des contraintes induites par un typage fort [...]
    Après la lecture de ce sujet et des articles de Wikipédia portant sur les types en programmation, je ne suis plus sûr de grand chose à propos de ce qu'on appelle typage fort et typage faible*. Mais j'aimerais bien connaitre ta source pour l'affirmation citée ci-dessus. Que penser de cet article, d'ailleurs ? Sinon, pour aller dans ton sens, l'un des objectifs des initiateurs du projet Dart (Bak et Lund) est de réduire drastiquement le nombre de conversions implicites effectuées par JavaScript et qui mènent parfois à des aberrations du genre 1 est égal à 2 (voir la vidéo en lien ci-avant). C'est peut-être ce à quoi tu pensais.

    * En tout cas, ce qui ressort de Wikipédia et des débats dans ce fil, c'est qu'il n'y a malheureusement pas de consensus pour définir la force d'un typage (cela a été dit dès la première page). D'ailleurs, l'article de Wikipédia sur ce sujet laisse penser (ce n'est que mon avis) que la force d'un système de types est la résultante assez subjective d'un ensemble de critères bien mieux définis, comme l'aspect statique/dynamique, l'inférence ou la sûreté. Cela dit, en général, il semble que le typage faible soit plus négativement connoté que le typage fort. En tout cas beaucoup plus, dans l'esprit des développeurs, que le typage statique ne l'est en regard du typage dynamique. En bref, ce serait carrément mieux vu d'adopter un typage fort.

    Je voulais revenir sur des définitions intéressantes données dans ce fil. En effet, l'article de Bovino passe bien trop vite sur les définitions (à dessein ?) et entretient certaines confusions. Mais ce reproche a déjà été formulé, principalement par grim7reaper. Grim7reaper, justement, qui évoquait les conversions implicites parmi les critères permettant selon lui de comparer les forces de typage de différents langages :
    Citation Envoyé par grim7reaper Voir le message
    Plus il y a de conversions implicites, plus le typage est faible (car il est plus facile de faire des conversions entre les types et de mélanger des types différents dans une même opération), à contrario moins de conversion [im]plicite => typage plus fort.
    Vu le nombre de votes positifs et les réactions qui ont suivi, il semble que ce critère ait emporté l'adhésion d'une large majorité. (Au passage cela fait écho à l'argument sur Dart)

    Et pouf, deux pages plus loin, une autre définition, donnée par sjrd et contre laquelle personne n'a vraiment bataillé non plus :
    Citation Envoyé par sjrd Voir le message
    Un langage est faiblement typé si et seulement si les casts non vérifiés au runtime sont autorisés. C++, par exemple, a des casts non vérifiés. Java, bien qu'ayant des casts, est fortement typé car tous les casts sont vérifiés valides au runtime.
    JavaScript n'a pas du tout de cast (il n'a que des conversions), donc a fortiori tous ses casts sont vérifiés.
    (Au passage, comme yahiko, j'aurais aimé connaitre la source, parce que résumé comme ça c'est un peu obscur : un cast, n'est-ce pas une forme de conversion ?)

    Darktib a répondu, sur un ton semi humoristique :
    Citation Envoyé par Darktib Voir le message
    S'il n'y a pas de cast, alors tous les casts sont à la fois vérifiés et non vérifiés (l'ensemble des casts étant l'ensemble vide). Ils sont aussi autorisés et non autorisés.
    Il en ressort que Javascript est à la fois faiblement et fortement typé
    Bien qu'un brin trollesque, je me serais arrêté à cette première partie du message. Pourquoi, dans la logique de sjrd, appliquer une définition faisant clairement mention des casts alors que sjrd lui-même considère qu'il n'y a pas de casts en Javascript ? La définition semble clairement inadaptée au cas de Javascript, dans ce cas, non ?

    Et que penser du fait que cette deuxième définition balaye complètement le critère donné par grim7reaper ? Moi qui ne suis pas un spécialiste de la théorie des types en programmation, j'avoue m'y perdre un peu...

  10. #10
    Membre émérite

    Profil pro
    Inscrit en
    Juin 2007
    Messages
    748
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2007
    Messages : 748
    Par défaut
    pour vous dire...

    en javascript comme en php et en java, la déclaration des constructeurs est quasi identique.

    ce qui peu changer, et du coup ca revient au typage fort ou faible, c'est l’appartenance véritable d'une variable à un groupe, et donc à son constructeur.

    Quand nous déclarons que la var A est dans le groupe de GROUPEDESA, celon certains langages et c'est ce qui en fait le typage fort, cette variable héritera tout au long de sa vie des propriétés du groupe dans lequel elle à été formé..

    Le typage fort implique que si une variable change de groupe, elle ne doit pas poser de problème de fonctionnement.

    admettons juste que une variable qui est un chiffre ne puisse pas rejoindre un groupe qui n'accepte pas les variables avec un chiffre.

  11. #11
    Invité de passage
    Inscrit en
    Mai 2009
    Messages
    1
    Détails du profil
    Informations forums :
    Inscription : Mai 2009
    Messages : 1
    Par défaut Javascript fortement typé ???
    J'ai peu utilisé javascript mais d'après les exemples, il semble que Javascript fasse parti des langages où c'est le contenu qui défini le type de la variable ?
    Un peu comme Lisp ?

    var totoAsChaine = '123' => c'est une chaîne
    var totoAsNombre = 123 => c'est un nombre

    La donnée est donc typée par son contenu contrairement aux langages où la donnée est typée lors de sa définition (C, C++, Java ...).

    String totoAsChaine = "123" ; => chaîne obligatoire...
    int totoAsNombre = 123 ; => nombre entier obligatoire...

    Ce qui n'empêche pas de faire des contrôles sur le type des variables et de lever des exceptions.

    Mais bon dire que c'est fortement typé c'est juste pour faire du buz non ?
    Dans un tel langage il faut contrôler en permanence le type des arguments non ? Dites moi que je me trompe...

  12. #12
    Membre très actif
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    547
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Comores

    Informations professionnelles :
    Activité : Directeur Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2010
    Messages : 547
    Par défaut
    Citation Envoyé par Bovino Voir le message
    La réalité, c'est qu'effectivement, tout opérateur renvoie un résultat en JavaScript, quitte à modifier le type de l'un des opérandes.

    Le typage dynamique n'affecte donc pas le type des opérandes.
    Dans quel langage, quelque soit le typage, les opérateur ou les fonctions, modifient le type des opérandes ou les variables passé en paramètre? Tant qu'il n y a aucune affectation quelque part sur les opérandes, que soit après ou inter instruction, ou en interne de l'objet qui appel la fonction, alors ils restent tel qu'ils sont.

    Le casting, le parsing , les appel de fonctions et toutes les instructions s'en chargent de retourner quelque chose qu'on veut, ils ne modifient jamais le contenu ou le type des variables, a moins que les variables soient aussi utilisés pour affecter la valeur retourné.

    C'est un principe de base de la programmation, et montrez moi un seul langage qui enfreint ce principe.

    Alors le fait que JavaScript suit ce principe de base de tous les langages, ça n'a rien rien n'avoir avec un typage faible ou fort.

    Citation Envoyé par Bovino Voir le message
    Pourquoi JavaScript serait un langage fortement typé ?
    La réponse courte serait tout simplement du fait de la présence d'erreurs de type en JavaScript !
    On travail avec JavaScript et les erreurs de type de JavaScript ne sont pas vraiment significatives, et ne servent pas à grand chose dans le cadre du typage.

    Rappelons que quand vous voulez appeler une fonction qui n'existe pas, et qu'avant les deux parenthèses d'appel ce n'est pas une fonction déjà défini ou une fonction en cours de définition, ou une variable qu'on a affecté une fonction, alors il va donner un message de Type error disant que tel n'est pas une fonction et si l'objet existe alors que vous appeler une méthode qui n'existe pas il va vous donner une erreur de type et vous dire tel objet ne contient pas tel fonction.

    Et si il reconnait le type de la variable autre que fonction, il va vous dire que le type de cette variable n'est pas une fonction.

    A ma modeste connaissance, JavaScript ne reconnait que cela pour donner un message "Type error", c'est l’inexistence de fonction ce qui ne peut en aucun cas faire l'objet d'un typage fort. Il peut vous dire dans certains cas que tel variable est indéfini, mais c'est une erreur de base.

    Loin du fait d'un typage dynamique, mais toute instruction est censé retourner quelque chose, s'il y a une erreur de type ça doit nous signaler. Alors dans le cas d'erreur de type autre que ce que j'ai mentionné, JavaScript quand il n'arrive pas à retourner quelque chose avec les opérandes ou fonction il va vous retourner null ou quelque chose de type undefined, et c'est tout.

    Il ne détecte pas les vrai erreurs de type.

    En faisant par exemple:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    a="djdj";
    b=2;
    c=b-a;
    //c=null
    c est égale à null, alors que JavaScript a su que "a" est de type string et "b" est de type nombre. Il ne peut jamais nous dire "on ne peut pas convertir un string en entier ! Jamais!!!
    Mais il se contente de nous retourner null.

    Mais viendrons par exemple en Java:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    String a="ddd";
    int b; 
    int c=b-a;
    Ce code ne va même pas se compiler le compilateur va vous dire qu'on ne peut pas convertir un string en entier.

    Et si on fait par exemple en JavaScript
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    String a="ddd";
    int b; 
    int c=b-parseInt(a);
    Il va juste vous retourner null, par contre en java par exemple
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    int a=2;
    String b="ddd";
    int c=a-Integer.parseInt(b);
    Il va compiler, mais lors de l’exécution il va vous retourner une vraie erreur de type en levant une Exception de type NumberFormatException.

    Le typage fort aussi peut entrer dans le cadre du nombre de type primitif, mais aussi de l'espace mémoire alloué pour chaque type de variable, et ça devient important maintenant que JavaScript fonctionne côté serveur. JavaScript gère seulement 3 type primitifs string, number et boolean, point barre. On ne peut pas le comparer par exemple à C/C++ ou java.

    Un type double en C n'est pas un type float, et un type int n'est pas un long , ils n'occupent la même espace mémoire.

    Pour conclure, JavaScript est typé comme tous les autres langages. Le fait qu'un langage comprenne le type des contenus des variables qu'il traite (à la limite ce qu'il sait gérer) est un pilier de chaque langage de programmation, sinon il ne pourra jamais faire des calcules.

    Mais si on veut classer le typage de JavaScript, je ne vois pas en quoi il peut se mettre au rend des langages à typage fort. Son typage est faible.

  13. #13
    Membre Expert
    Avatar de Kaamo
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    1 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Avril 2007
    Messages : 1 165
    Par défaut
    Dans quel langage, quelque soit le typage, les opérateur ou les fonctions, modifient le type des opérandes ou les variables passé en paramètre? Tant qu'il n y a aucune affectation quelque part sur les opérandes, que soit après ou inter instruction, ou en interne de l'objet qui appel la fonction, alors ils restent tel qu'ils sont.
    Je n'ai pas compris

    a="djdj";
    b=2;
    c=b-a;
    //c=null
    Quelle machine JavaScript utilises tu ? Chez moi il retourne NaN
    c est égale à null, alors que JavaScript a su que "a" est de type string et "b" est de type nombre. Il ne peut jamais nous dire "on ne peut pas convertir un string en entier ! Jamais!!!
    JavaScript convertit implicitement des string en entier, quand c'est possible. Sinon il utilise NaN. C'est sa façon de dire qu'il ne peut pas convertir implicitement l'opérande en entier.
    Bien sûr, la valeur de la variable (opérande) n'est pas modifiée mais elle est implicitement convertie durant une opération sur celle-ci.
    Exemples :
    Code javascript : 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
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    // Conversion implicite des string en number
    var a = '5';
    var b = '3';
    console.log(a - b, typeof (a-b)); // 2, number. Les opérandes sont implicitement converties durant le calcul et donnent un résultat de type number
    // Par contre, les opérandes ne sont pas modifiées
    console.log(a, typeof a); // '5', string
    console.log(b, typeof b); // '3', string
     
    // Conversion implicite en boolean
    // Grâce à ce principe, l'instruction if, par exemple, peut prendre n'importe quelle valeur.
    var testedValues = [undefined, null, false, -0, +0, NaN, '', 1, -1, 'a', true, Infinity, {}, []], len = testedValues.length, i = 0;
    for (; i<len ; i++) {
      console.log(testedValues[i] + ' => implicitement convertie à ' + (testedValues[i] ? 'true' : 'false'));
    }
    /*
    Tu l'auras compris, undefined, null, false, -0, +0, NaN, '' sont implicitement convertis en false, le reste à true
     
    undefined => implicitement convertie à false
    null => implicitement convertie à false
    false => implicitement convertie à false
    0 => implicitement convertie à false
    0 => implicitement convertie à false
    NaN => implicitement convertie à false
    '' => implicitement convertie à false
    1 => implicitement convertie à true
    -1 => implicitement convertie à true
    a => implicitement convertie à true
    true => implicitement convertie à true
    Infinity => implicitement convertie à true
    [object Object] => implicitement convertie à true
    [] => implicitement convertie à true 
    */
     
    // Conversion implicite en string
    // l'opérateur + est particulier. Il a le rôle de concaténation de string et d'addition de number. Analyse de l'expression de gauche à droite. Rant qu'il rencontre des number : addition. Dès qu'une string apparaît : concaténation.
    var x = '5';
    console.log(x + 1); // 51
    console.log(1 + x); // 15
    console.log(1 + 3 + x); // 45
     
    // Conversion implicite des Object en string ou en number
    // Quand JavaScript attend un string ou un number (exemple lors d'une concaténation / addition), il va tenter de convertir l'objet dans le type souhaité.
     
    // Si JavaScript attend un number, mais qu'il rencontre un Object : Il va checker s'il contient une méthode valueOf, si oui, retourne la valeur. Sinon, il check s'il contient une méthode toString, si oui, retourne la valeur. Sinon, NaN.
    var a = { valueOf: function () { return 5 } };
    3 * a; // 15, se sert de valueOf()
    var a = { bipbip: function () { return 5 }, toString: function () { return 7 } };
    3 * a; // 21, se sert de toString()
    var a = { bipbip: function () { return 5 } };
    3 * a; // NaN, pas de méthode valueOf ou toString
     
    // Si JavaScript attend une string, même principe que ci-dessus
    var a = { toString: function () { return 'toto' } };
    'je suis ' + a; // "je suis toto", se sert de toString  de l'objet a
    var a = { bipbip: function () { return 'toto' } };
    'je suis ' + a; // 'je suis [object Object]',  toString  est absent dans a, donc se sert de toString de a.prototype (soit la méthode toString native de Object).

    Pour quoi cette conversion implicite ? Car JavaScript, dans sa première version, n'avait pas la gestion des erreurs (comprendre bloc try{}catch() voir (1) ). Pas de gestion des erreurs => conversion implicite + échoue silencieusement.

    JavaScript gère seulement 3 type primitifs string, number et boolean, point barre
    Il y a aussi undefined et null (2), qui sont des cas particuliers car pas d'objet "wrapers" associés.

    Pour conclure, JavaScript est typé comme tous les autres langages

    Mais si on veut classer le typage de JavaScript, je ne vois pas en quoi il peut se mettre au rend des langages à typage fort. Son typage est faible.
    Qu'est-ce qu'un typage faible ? A l'instar du typage fort, il n'y a pas de réelle définition. Mieux vaut parler de typage dynamique ou statique.

    JavaScript a un typage à "tendance dynamique". Les types des variables ne sont pas connus au moment de la compilation (parsing). Ils le sont par contre à l'exécution. Et encore, il ne contrôle pas tout :
    Code javascript : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    // null, il jette une erreur
    var a = null;
    a.prop; // TypeError: Cannot read property 'prop' of null
     
    // object, il ne bronche pas
    var a = {};
    a.prop; // silencieux, undefined

    Comme je l'ai écrit un peu avant dans cette discussion :

    Je dirais que Javascript a un typage à "tendance dynamique" et plus particulièrement un "typage canard" (voir Duck Typing).
    Cela veut dire que Javascript ne va pas vérifier le type de la variable avant de réaliser ce qu'on lui demande, mais va tout simplement vérifier si la variable peut réaliser ce qu'on lui demande.
    Code javascript : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    var donald = {};
    donald.bafouille(); // Object #<Object> has no method 'bafouille'
     
    donald.bafouille = function bafouille() {
      console.log('Kshhshsh blblbl');
    }
    donald.bafouille(); // Kshhshsh blblbl

    Source :
    (1) Tweet Brendan Eich
    (2) ECMA spéc.

  14. #14
    Membre très actif
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    547
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Comores

    Informations professionnelles :
    Activité : Directeur Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2010
    Messages : 547
    Par défaut
    Citation Envoyé par Kaamo Voir le message
    Je n'ai pas compris
    J'ai lu tout le message de bovino , et il nous a fait comprendre comme quoi la manipulation des opérandes n'affecte pas le type de ces opérandes, c'est pour celà que le typage dynamique ne modifient pas le type des variables. Moi j'ai demandé quel language fait le contraire?

    Comment une opérande, un paramètre de fonction ou objet qui appel une fonction, peut être modifié alors qu'acune affectation quelque part n'est fait?

    Il a donné par exemple un exemple ici:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    var tab = [1,2,3];
    tab.join(',');
    console.log(Array.isArray(tab)); // true
    La méthode join() a renvoyé une valeur de type chaine, mais n'a pas touché au type de tab.
    Mais la question que je me demande quel language allait modifié le type de tab alors la fonction join() ne s'en charge pas de modifier le status de tab dans son espace mémoire, mais de prendre ce qui est là et le manipuler, pour retourner quelque chose, tant qu'il n y a pas d'affectation ou destruction quelque part(déjà un objet ne peut jamais se détruire lui même), tous les languages objets fonctionnent ainsi, la référence et le type resterons tel qu'ils sont.

  15. #15
    Membre Expert
    Avatar de Kaamo
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    1 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Avril 2007
    Messages : 1 165
    Par défaut
    Mais la question que je me demande quel language allait modifié le type de tab
    join ne modifie pas tab .. mais la plupart des méthodes d'Array modifie l'occurrence. Par exemple :
    Code javascript : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    var tab = [1,2,3];
    tab.push(4);
    console.log(tab); // [1, 2, 3, 4] 
     
    var tab = [3,2,1];
    tab.sort();
    console.log(tab); // [1, 2, 3]
    Sans qu'il n'y ait eu d'affectation

  16. #16
    Membre très actif
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    547
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Comores

    Informations professionnelles :
    Activité : Directeur Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2010
    Messages : 547
    Par défaut
    Citation Envoyé par Kaamo Voir le message
    join ne modifie pas tab .. mais la plupart des méthodes d'Array modifie l'occurrence. Par exemple :
    Code javascript : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    var tab = [1,2,3];
    tab.push(4);
    console.log(tab); // [1, 2, 3, 4] 
     
    var tab = [3,2,1];
    tab.sort();
    console.log(tab); // [1, 2, 3]
    Sans qu'il n'y ait eu d'affectation
    Je suis désolé, a mon avis tu n'a pas compris ma question, ton exemple est loin de ce que j'ai posé comme question. Ce que tu vient de faire, tu as juste apporter des modifications sur le contenu de l'objet de type Array. Mais tu n'a pas modifié le type , tab reste de type Array.

    Par contre si on fait:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    var a=[1,2,3,4];
    var f=a.join(',');
    //typeof(f)==string;
    Pour tous les langages le type d'un objet sera modifié, si tout simplement on affecte sur lui même quelque chose objet=machin, ou bien on le détruit, qu'il pointe vers null, ou autre objet, ou variable.

    Citation Envoyé par Kaamo Voir le message
    JavaScript convertit implicitement des string en entier, quand c'est possible. Sinon il utilise NaN. C'est sa façon de dire qu'il ne peut pas convertir implicitement l'opérande en entier.
    C'est ça façon de "dire", ou c'est sont choix de retour. Car comme je l'ai dis toute instruction doit retourner quelque chose. JavaScript doit absolument retourner quelque chose, ou rompre le programme en signalant qu'il n peut rien retourner car il y a des erreurs. Pour ce cas là il retourne NaN mais comme si tout va bien.

    Les concepteurs du langage considèrent que c'est un comportement normal qui ne doit pas rompre le programme ou renvoyer un message d'erreur.

    Le problème, c'est que dans ce genre de situation, on peux perdre beaucoup du temps à chercher où est l'erreur, si on avait pas demandé d'afficher le résultat qui renvoie NaN. Soyons sérieux on ne peut pas demander d'afficher tout variable qu'on va convertir, sinon ça serait un programme de log.

    Alors on appel pas ça "dire", car on sait bien que tout ne va pas, il faut au moins un message d'erreur, si on ne rompe pas le programme, pour aider le développeur à comprendre les erreurs qu'il fait. Un langage c'est pour coder, mais c'est aussi pour parler avec le développeur afin qu'il réussisse aisément sa mission, sinon aucun langage n'allait renvoyer des message d'erreur.

    Citation Envoyé par Kaamo Voir le message
    Bien sûr, la valeur de la variable (opérande) n'est pas modifiée mais elle est implicitement convertie durant une opération sur celle-ci.
    La conversion implicite, c'est une nouvelle donnée et un espace mémoire que la convertie sera placée, la source reste non touchée.

    Soyons claire, certes il n y a pas de définition pour dire quel tel est de typage fort ou faible. Mais les langages sont le fruit de l'homme, quand il veut fortifier un concept il le fait et quand il veut rendre les choses un peu souple, sans tenir trop de paramètre, il le fait aussi. Ce n'est pas un bon matin que beaucoup de concepteurs de langages ont choisit d'être sévère sur les types, (pas dans son contexte dynamique ou static), mais sur la manière de gérer leurs comportement au sein d'un programme si c'est fortifié ou le contraire.

    A l'appui de ce que je dis, Bovino a voulu donner à l'appuis de ce qu'il disait le fait du renvoie de message d'erreur de type. Mais malheureusement, JavaScript ne renvoie celà que s'il ne trouve pas de fonction. Seulement! Or une fonction n'est même pas un type primitif.

  17. #17
    Expert confirmé
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Par défaut
    heu j'ai la berlue ou quoi

    tu applique une méthode de tri à un tableau
    je ne vois pas en quoi il serait anormal que le tableau en sorte trié.

    le type de base array comme en C ou Java n'existe pas
    le type Array de javaScript c'est comme si tu avais la classe java
    Code java : 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
    public class Array
    {
     
       private ArrayList<Object> data = new ArrayList<Object>();
     
       public Array(Object... initData) {
          for(Object object : initData){
             data.add(object);
          }
       }
     
       public Array reverse() {
          ArrayList<Object> nData = new ArrayList<Object>();
          int size = data.size();
          for(int i = 0; i < size; i++){
             nData.add(size - i, data.get(i));
          }
          data = nData;
          return this;
       }
     
    }
    Je ne vois pas ce qu'il y a d'étrange dans
    Code java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    Array tab = new Array(4, 3, 2, 1); // [4, 3, 2, 1] 
    tab.reverse();// [1, 2, 3, 4]
    C'est exactement ce que tu demande.

    il n'y a là aucune magie ou d'effet de bord ou quoi que ce soit.
    la méthode sort tri le tableau et le retourne c'est sa spec
    ce n'est pas une méthode qui retourne une copie trié.

    on peu ne pas être d'accords sur le fait d'avoir choisi cette spec mais ça n'a rien avoir avec le langage.

    On a la même chose en C++
    la méthode String.Append ajoute une string à l'objet courant
    la méthode String.Concat retourne la concaténation des deux chaines
    on choisit celle qu'on veut.

    Pour Array.sort javascript à choisit d'implémenter la méthode qui tri le tableau sachant qu'une méthode existe pour avoir une copie.

    si tu veux une copie trié et non trier le tableau lui même se choix permet de savoir à coup sur ce que tu tri.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    var tab = [3,2,1];  // [3,2,1]
    var copyTrie = tab.slice(0).sort(); // obtenir une copie trié On voit bien la copie puis le tri de la copie.
    console.log(copyTrie ); // [1, 2, 3]
    console.log(tab);  // [3,2,1]
    tab.sort();
    console.log(tab); // [1, 2, 3]
    Ce n'est pas parce que tu CROIS que les tableau JavaScript sont des Object[] Java ou C++ que c'est le cas.
    Array est une structure de donnée qui à sa spec et qui est cohérente. c'est un objet (ou une classe) comme on en trouve dans tous les langage à objet.

    JavaScript à fait le choix de ne pas avoir de type de base Object[] comme Java C C++ etc.
    et ce choix vaut aussi pour les String qui ne sont pas des char[]en fait JavaScript à défini des types de base qui sont des "Classes" bref le littéraux sont des Objets
    On peut donc écrire des chose comme
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    true.toString();
    //ou 
    "test".charAt(2);
    //ou 
    [4, 3, 2, 1].sort()[2]
    Il y a malheureusement JS n'est pas parfait une exception à cela il s'agit des nombres
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    15.3.toString(); // "15.3"
    15.toString(); //SyntaxError: Unexpected token ILLEGAL
    cela est du à la notation pointé.
    en javascript on utilise objet.method() ou objet.attribut pour accéder à un membre
    et un nombre littéral en Javascript est un object de type Number
    mais un Number peut contenir un . ce . est le séparateur des unités. lorsqu'on utilise un littéral 15 ou 15.3 on a bien un number
    mais à l'analyse syntaxique le compilateur js interprète toujours le premier . comme étant le séparateur des unité et non comme l'accès à un membre.
    JS offre la possibilité d'utiliser l'accès par nom objet["nomMembre"] que ce soit pour une méthode ou un attribut et on peu constater que le littéral 15 est bien un objet comme les autre en faisant
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    15["toString"](); //"15"
    Je crois qu'encore une fois tout cela relève d'une méconnaissance et non d'un langage qui serait mal fait.
    Si on prends les définitions des types JS Array
    JS Boolean
    JS Date
    JS Math
    JS Number
    JS String
    JS RegExp
    JS Global
    qu'on implémente des classes Java qui ont le même comportement on pourra voir que ces Classes sont parfaitement utilisables
    Elle n'on rien d'extraordinaire.
    Tout ce que je viens de lire sur les problème de codification non voulu des objets ne sont en fait que une non connaissance de l'API.

    Je pourrais formuler la même critique à PHP lorsqu'on tri un tableau il est trié. C'est pas normal.
    ben si C'est normal : c'est la définition de la fonction de tri array_sort qui tri le tableau pas une copie

    A+JYT
    PS: Pour tout langage à base de classe on lit la doc d el'API pour l'utiliser au mieux pourquoi en javascript les développeurs s'imagine qu'il n'y a que 4 fonctions et pas de structure ? lisez la spec ouvrez l'api
    http://www.ecma-international.org/ecma-262/5.1/

  18. #18
    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
    Par défaut
    pour moi, un langage fortement typé, c'est un langage qui dit :
    "On mélange les bananes avec les pommes!" (comprendre : on fait pas "1"+1, car sinon on sait pas si ça fait 2 ou 11)
    Du coup, Python est un langage fortement typé, JS un langage faiblement typé.
    Il y a différentes sortes de langages fortement typés :
    -Les bizzares, qui n'affichent rien comme résultat. Ex: C
    -Les logiques, qui affichent une erreur. Ex : Python

    Du côté des faiblements typés, il y a ceux qui disent :
    Pour éviter de planter quand on fait "string"+1, on va mettre les strings vont être propriétaire. "1"+1="11". Ex : JS
    C'est l'opération qui décide du type et non l'inverse. "1"+1=2, parceque "+" sert à l'addition et à rien d'autre. Ex : Perl

  19. #19
    Membre très actif
    Avatar de la.lune
    Homme Profil pro
    Directeur Technique
    Inscrit en
    Décembre 2010
    Messages
    547
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Comores

    Informations professionnelles :
    Activité : Directeur Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2010
    Messages : 547
    Par défaut
    Citation Envoyé par sosolal Voir le message
    pour moi, un langage fortement typé, c'est un langage qui dit :
    "On mélange les bananes avec les pommes!" (comprendre : on fait pas "1"+1, car sinon on sait pas si ça fait 2 ou 11)
    Du coup, Python est un langage fortement typé, JS un langage faiblement typé.
    Il y a différentes sortes de langages fortement typés :
    -Les bizzares, qui n'affichent rien comme résultat. Ex: C
    -Les logiques, qui affichent une erreur. Ex : Python
    Le langage C est un langage faiblement typé, il est juste à typage static. Un langage fortement typé c'est le compilateur qui doit détecter les irrégularités de type avant exécution et une fois aussi joué le compilateur en respectant les normes mais avec de fausses données il faut que le langage soit aussi capable de dire que ça ne va pas et que c'est due au type. De la même chose pour les langages interprétés l’interpréteur doit être capable de signaleur en donnant un message d'erreur pour toutes irrégularités liés aux types. Alors il faut respecter les deux conditions qui suivent, voir wikipédia.
    Un langage est fortement typé si :
    1. 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é ;
    2. les conversions implicites de types sont formellement interdites. Si de telles conversions sont possibles, le langage est faiblement typé
    Au moins le typage faible a bien une définition, si on trouve que les deux conditions posés dans la définit ne sont pas vérifiés et détectés comme erreur en cas d'enfreint alors c'est fini le langage est typage faible.

    Mais, là vient la question sur le langage à typage fort, là le débat est sans limite, car certains vont dire que si un tel langage respecte au moins une des deux conditions peut on le classer fort ou faible. Ce qui est sûr si les deux conditions sont à la fois respectés alors le langage est fortement typé sans discussion.

  20. #20
    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
    Par défaut
    Je dirais que seul le deuxième point de la définition qui compte. Le premier n'a rien avoir avec la force du typage : tout langage avec un minimum de logique devrait avoir ça, indépendamment de la force de son typage. Parce qu'additionner des objets de type Banane avec des objets de type Voiture, ce n'est absolument pas logique, indépendamment de la force de typage. (À moins que ça fasse un objet de type BananeEcrasee, faut voir.)

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