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

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 4 007
    Points : 8 855
    Points
    8 855

    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
    531
    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 : 531
    Points : 2 051
    Points
    2 051

    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 007
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 4 007
    Points : 8 855
    Points
    8 855

    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
    6
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2009
    Messages : 6
    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.

Discussions similaires

  1. Réponses: 30
    Dernier message: 20/09/2012, 14h25
  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