Discussion :

[sekaijin]

je trouve cela complètement absurde.

ramener le faiblement typé au fait qu'on peut faire "1" + 1.

cela n'est qu'une question de définition de l'opérateur +
ce n'est pas parce que le compilateur interdit de changer le type d'un objet qu'on ne peut pas définir des opérateurs qui prennent des opérandes de type différents.

il est tout aussi faux de dire que JS est faiblement typé parce qu'on peut écrire ce genre d'expression.
Si j'écris add("1", 1) il devient fortement typé ?

la nature des objets à changé ?

je trouve tout aussi absurde de dire qu'un langage est faiblement typé parce qu'il permet d'affecter à une variable un Integer puis une String.
C++ et Java sont faiblement typé alors.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Object a = new Integer(5);
a = new String();

et enfin je pense que beaucoup confondent les noms de leurs objets dans leur code source est les variables dans la mémoire. un nom est un nom et rien de plus.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
var a = new Integer(5);
var b = a;
a = "test";

un prog C++ qui ferait ce genre de chose produirait un code exécutable où ni a ni b n'existe en mémoire seuls l'entier 5 et la chaine "test" existerait.

JS garde la liste des noms (besoin pour l'interprétation) cela en fait-il un objet en mémoire ?
les nom des variables ne sont rien de plus que des références.
viendrait-il à l'idée de quelqu'un de dire que les objets vont changer de nature parce qu'ils sont référencés par une référence de type void& ou Object

pour reprendre le propos du premier post de cette discussion
prenez un langage considéré comme fortement type genre C++ ou Java
développez en utilisant uniquement des variables et des paramètres de fonction de type void& ou Object.

et vous aurez les même capacités que celle de JS concernant vos variables.
cela fait-il de ces langages des langages faiblement typés ?

A+JYT

[la.lune]

ramener le faiblement typé au fait qu'on peut faire "1" + 1.
cela n'est qu'une question de définition de l'opérateur +

il est tout aussi faux de dire que JS est faiblement typé parce qu'on peut écrire ce genre d'expression.
Si j'écris add("1", 1) il devient fortement typé ?

Je partage avec vous que le faiblement typé n'est pas lié au fait de faire "1"+1, car c'est juste la définition. Seulement il n y a une différence entre
"1" + 1 et add("1", 1) , car d'abord ce qui est sûr c'est que la signature est soit add(Object,Object) ou s'il y a bien un surcharge de la méthode comme ça: add(String,Integer) et add(Integer,String) et add(String,String) ..., un des méthodes est bien choisit.

Ce qui est sûr add("1",1) te donnera sans doute 2, et non pas "11". Si je veux faire "11" on appel pas ça AJOUTER, c'est ce qui fait que dans ce cas on utilise la méthode concat()

Tout reste que moi je ne vois pas le vrai problème lorsqu'on travail avec des variables de type Object, tant que les normes préalablement définis sont respectés et pour moi il n'est pas question de nom de variables. Avant d'avancer reculons un peu pour voir: l'opérateur + par exemple en Java et JavaScript s'utilisent pour ajouter des nombres et concaténer, il y a une règle en commun c'est que tant qu'il y a une chaîne au milieu alors le résultat final sera une chaîne et tout ce qui est avant la chaîne sera évalué et tout ce qui est après la chaîne s'il n a pas de parenthèse et ben il sera concaténé.
C'est pour cela que j'arrive à écrire des trucs comme ça en Java:

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 Object a=1+2;//a=3 
         a="1"+"2";//a=="12"
         a="1"+2; //a=="12"
         a=1+2+"3";//a==(1+2)+"3"=="33"
         a=1-2+"3";//a==(1-2)+"3"=="-13"
         a="1"+2+3;//a=="12"+3=="123"
         a="1"+(2-3);//a=="1-1"
         a=1+2+"3"+4;//a==(1+2)+"34"=="334" 
         a=new String("2")+new String("3");//b=="23"
         a=new Integer("2")+new String("3");//b=="23"
         a=new Integer("2")+new Integer(3);//b==new Integer(5)
a=new Integer("3")-new Integer("2")+new String("3");//b=="23"

Mais ça s’arrête là vu que l'opérateur + a été surchargé pour la concaténation, du coup il fallait un certains nombre de règles à appliquer, ainsi si je veux faire "1"-2 ou ça a="1"+2-3;, il va refusé, c'est une erreur de compilation car aucune règle d'utilisation de l’opérateur - pour des chaîne, on a surchargé + à la limite pour faciliter des milliers de taches répétitives de concaténation, et qu'enfin ça vous donnera toujours des chaines, mais il est hors de question de faire des calculs sur des chaines. On pourrait utiliser le <.> comme en php, mais le jeu serait le même.

Un tableau de caractère ça reste un tableau de caractère, si vous êtes sûr ce que vous voulez convertissez le. Ce qui est important ici c'est que l'exception a été donné seulement à l'objet de type String, et dés que ce dernier se trouve dans l’instruction alors il sera obligatoirement le type du résultat final on sort carrément du cadre de calcul, ça reste de la concaténation et le type est déjà défini et connu comme type final. D'autres objets n'ont pas de places ici.

Mais en JavaScript ils mélangent tout à part le fait de permettre des conversion implicites des chaines, mais tu peux tout mélanger à la fois faire des calculs sur n'importe quoi, un truc comme ça par exemple:
var a=new Array()+new Number(4)-new String("2")+new Boolean(true); a==3
var b=12/['2']+['2','3'];a=="62,3"
Du coup, au delà des règles fixés en cas de présence de chaîne, JavaScript devient un peu bordélique en typage.

En plus de ça si je me permet de mettre de fausses données il va seulement me retourner NaN sans me dire que ce qui lui a causé tout ça, il est incapable de dire "Eh je n'arrive pas à convertir un tel en tel, ou calculer tel avec tel" non, il se tais et retourne NaN et si c'est dans des milliers de lignes de code: un jeux par exemple où on manipule beaucoup les nombres c'est fini toute la journée va passer là, car il ne te dira rien. Ça bug c'est tout.

Du coup si en Java je fais
a=new Integer("b")+new Integer("2"); ça va compiler mais, quand ça ne va pas marcher avec le b quand il voudra convertir, tu saura là où est l'erreur et même la ligne exacte et toute la pile des méthodes infectés.

prenez un langage considéré comme fortement type genre C++ ou Java
développez en utilisant uniquement des variables et des paramètres de fonction de type void& ou Object.

Non, car ce qui est après la variable de type Object est évalué et enfin un objet est retourné à la fin, et mis dans Object, certes si je teste son type je saurais de quel type il s'agit
En JavaScript je peux faire:

Code JavaScript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
var a=2;
var b=3
var c=a+b;//c==5

Mais je ne peux pas faire en Java ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Object a=2;        
Object b=3;
Object c=a+b;//ERREUR DE COMPILATION

Le compilateur dira qu'il n y a pas de calcul sur des Objet, le typage fort oblige, je dois faire ceci pour que ça marche:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Object c=((Integer)a)+((Integer)b); c==new Integer(5)

J'ai vu dans un de tes messages ici, faire une comparaison sur entre JavaScript et Java en montrant comme quoi Java oblige d'ajouter une variable de plus c'était ça:

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Object obj = myMap.get("truc");
if (obj instenceof Machin) {
Machin truc = (Machin)obj;
truc.myMethod();
}

et

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
var truc = myMap.get("truc");
if (truc instanceof Machin) {
truc.myMethod();
}

Je tiens à rappeler que c'est juste toi qui a ajouter cette variable, mais je ne suis obligé de l'ajouter, juste un casting de plus, je peux faire tout court en Java:

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Object truc = myMap.get("truc");
if (truc instenceof Machin) {
((Machin)truc).myMethod();
}

[phildepantin]

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.

[pterrat]

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

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

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

Exemple de classe en TypeScript :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
class Lion extends Animal {
  sex: string;
 
  constructor(name: string, sex: string) {
    super(name);
 
    this.sex = sex;
  }
 
  shout(): string {
    return "Rooooaarrr!"
  }
}

La même en VanillaJs (Javascript natif)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
var __extends = (this && this.__extends) || (function () {
    var extendStatics = Object.setPrototypeOf ||
        ({ __proto__: [] } instanceof Array && function (d, b) { d.__proto__ = b; }) ||
        function (d, b) { for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p]; };
    return function (d, b) {
        extendStatics(d, b);
        function __() { this.constructor = d; }
        d.prototype = b === null ? Object.create(b) : (__.prototype = b.prototype, new __());
    };
})();
var Lion = /** @class */ (function (_super) {
    __extends(Lion, _super);
    function Lion(name, sex) {
        var _this = _super.call(this, name) || this;
        _this.sex = sex;
        return _this;
    }
    Lion.prototype.shout = function () {
        return "Rooooaarrr!";
    };
    return Lion;
}(Animal));

Si vous voulez en savoir plus sur les différents types en TypeScript, vous pouvez aller voir cet article

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

[SylvainPV]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class Animal {
	constructor(name){
		this.name = name;
    }
}
 
 
class Lion extends Animal {
  constructor(name, sex) {
    super(name);
 
    this.sex = sex;
  }
 
  shout() {
    return "Rooooaarrr!"
  }
}
 
 
const simba = new Lion()
simba.shout()

Typescript se calque volontairement sur les évolutions du langage JavaScript pour maintenir son interopérabilité (on peut renommer un *.js en *.ts et ça doit compiler). On peut vanter les syntaxes spécifiques TypeScript comme les enums ou le JSX, mais pour ce qui est des classes, ça fait partie du standard

[pterrat]

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

[Gabbby]

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

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

[psychadelic]

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

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

En fait, je suis relativement d'accord avec ce qu tu a écrit, jusqu'a

- non JS n'est pas un langage objet :...

je te renvois à l'article de sylvainpv Onze idées fausses sur l'héritage en JavaScript
mais il doit y avoir d'autres, car que tu le veuilles ou non JavaScrit est un langage Objet, mais qui n'utilise pas un mécanisme par classes mais par prototypes.
Ce qui est presque normal puisque c'est un langage interprété.

C'est un langage de script qui permet seulement de singer les vrais langages objets !

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

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

https://madnight.github.io/githut/#/...equests/2017/4
https://insights.stackoverflow.com/s...017#technology

[tomlev]

- un langage fortement typé objet respecte la hiérarchie des classes : il applique le principe de Liskov (principe de la programmation objet)

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

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

[SylvainPV]

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

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

[Uther]

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

Utiliser un langage de haut niveau est tout a fait possible, ça marche déjà plutôt bien par exemple avec C++ et Rust. Le principe de base, c'est que si on peut faire du bas niveau, on peut en principe faire du haut niveau vu que le haut niveau repose sur l'utilisation cadrée de concepts de bas niveau. L'inverse est plus difficile, même si ça n'est pas complètement impossible comme l'a montré asm.js.
Actuellement, le seul souci est pour les langages avec leur propre garbage collector qui ne peuvent pas partager directement leur objets avec JavaScript car les deux Garbage collector pourraient entrer en conflit. Mais il est prévu à l'avenir de permettre a WASM d'interagir directement avec le Garbage Collector du moteur JavaScript pour résoudre ce problème.

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

Des concours du genre de la js1k ne sont pas l’apanage du JavaScript, il y en a avec tout type de technologie.
De plus on ne peut pas comparer du code géré automatiquement et écrit à la main. Le code compilé a partir qu'autres langages est rarement optimal en taille.
Enfin, le WASM a été pensé pour être efficace en terme de taille et de performance. Son avenir en tant que cible de compilation me semble clair.

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