Discussion :

[Paleo]

En pratique, je ne vois pas comment utiliser conjointement TypeScript et ObjectModel. Typer à la fois statiquement et dynamiquement n'a pas de sens, on combine les inconvénients et on perd les avantages.

Pourquoi pas ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
declare var Model;
interface Person {
	id: number;
	name: string;
}
let PersonModel = new Model({
	id: Number,
	name: String
});
let p: Person = new PersonModel(JSON.parse('...')); // contrôle par ObjectModel
console.log(p.name); // assistance à la saisie sur "p."

Le code généré :

Code :

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

1
2
3
4
5
6
var PersonModel = new Model({
    id: Number,
    name: String
});
var p = new PersonModel(JSON.parse('...'));
console.log(p.name);

La double définition n'est pas DRY, c'est vrai. Mais dans un projet TS, ObjectModel peut jouer son rôle de validateur pour des données venant de l'extérieur du programme.

[Paleo]

En fait, dans le cadre d'un projet TS, une version light de ObjectModel pourrait ne vérifier le typage qu'une seule fois (à l'import d'un objet JSON par exemple).
Quelque chose comme ça :

Code :

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

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

[SylvainPV]

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

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

[Paleo]

- on perd l'avantage du typage dynamique de pouvoir muter les types et les conditions de validation pendant l'exécution

Les avantages du typage dynamique ne sont pas perdus avec TypeScript. Pourrait-on voir un exemple concret ?

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

OK mais la validation d'une arborescence JSON est en tout cas un besoin récurrent, en TS autant qu'en JS.

[SylvainPV]

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

Code :

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

Person.assert(function(p){ return p.age >= 18; });

Ici c'est une assertion donc on pourrait dire que ça sort du cadre du typage, mais je pourrais trouver un autre exemple où les ID deviennent des String et non plus des nombres.

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

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

[Paleo]

Ici c'est une assertion donc on pourrait dire que ça sort du cadre du typage, mais je pourrais trouver un autre exemple où les ID deviennent des String et non plus des nombres.

Oublions les classes car elles appartiennent à ES6 et non à TypeScript. Prenons les identifiants number vs string. Admettons que nous ayons deux fonctions qui prennent presque le même type d'objet en paramètre. Nous pouvons procéder ainsi :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
interface Person {
	id: number;
	name: string;
}
interface PersonVariant {
	id: string;
	name: string;
}
function f1(p: Person) {
	p.id; // autocompletion: id is a number
}
function f2(p: PersonVariant) {
	p.id; // autocompletion: id is a string
}
let p: any = {
	id: 12,
	name: 'John'
}; // nous utilisons le type "any" afin d'annuler la définition par inférence
f1(p);
p.id = '12';
f2(p);

Je l'ai écrit plus haut : TypeScript est un mécanisme comparable à JSDoc, en beaucoup plus puissant et réutilisable. Il ne contrôle que le contrat que nous lui donnons à valider. Et l'outil le plus souple pour définir ce contrat, c'est l'interface.

[SylvainPV]

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

Au final, j'ai quand même réussi à rouvrir le débat dynamique vs statique Je vais donc copier/coller le résumé du débat de cet excellent article de Smashing Magazine, qui je pense fait le tour du sujet :

The static programmer says:	The dynamic programmer says:
“Static typing catches bugs with the compiler and keeps you out of trouble.”	“Static typing only catches some bugs, and you can’t trust the compiler to do your testing.”
“Static languages are easier to read because they’re more explicit about what the code does.”	“Dynamic languages are easier to read because you write less code.”
“At least I know that the code compiles.”	“Just because the code compiles doesn’t mean it runs.”
“I trust the static typing to make sure my team writes good code.”	“The compiler doesn’t stop you from writing bad code.”
“Debugging an unknown object is impossible.”	“Debugging overly complex object hierarchies is unbearable.”
“Compiler bugs happen at midmorning in my office; runtime bugs happen at midnight for my customers.”	“There’s no replacement for testing, and unit tests find more issues than the compiler ever could.”

http://www.smashingmagazine.com/2013...-type-systems/

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

[yahiko]

Mais si je peux me permettre un conseil, parler de "régression mentale" n'est jamais le meilleur moyen de démarrer posément un débat

Pour être exact j'ai employé l'expression "Régression des mentalités" nuance. Pour la simple raison que les langages à typage dynamique correspondent plutôt aux débuts de l'informatique : L'assembleur pouvant être considéré comme non typé (ou monotype), le FORTRAN, le LISP ou le BASIC.

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

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

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

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

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

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

[Paleo]

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

En JavaScript, on utilise JSDoc pour documenter les paramètres d'une fonction, et pourtant, il est impossible de changer dynamiquement un JSDoc. Est-ce que ça fait de JavaScript un langage au typage statique ?

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

En JavaScript (18 lignes) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
/**
 * @param p object {
 * 	id: number;
 * 	name: string;
 * }
 */
function f1(p) {
  p.name; // pas d'aide à la saisie :(
}
/**
 * @param p object {
 * 	id: number;
 * 	name: string;
 * }
 */
function f2(p) {
  p.name; // pas d'aide à la saisie :(
}

En TypeScript (10 lignes) :

Code :

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

1
2
3
4
5
6
7
8
9
10
interface Person {
	id: number;
	name: string;
}
function f1(p: Person) {
  p.name; // aide à la saisie :)
}
function f2(p: Person) {
  p.name; // aide à la saisie :)
}

Il n'y a pas photo.

[Paleo]

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

Pour moi la régression c'est quand TS passe du temps à implémenter des mot-clés "abstract" ou "protected", ce qui montre que certains développeurs refont en TypeScript une prison mentale comparable à celles des langages de la POO classique. Le risque, c'est que des frameworks pourris suivent et entrainent dans TypeScript toute la pesanteur du monde Java, un peu comme c'est le cas en PHP. PHP est un langage dynamique plutôt fun mais les offres d'emploi sont toutes à vomir à cause des Symfony, Smarty et consorts. Pour le moment dans l'écosystème JavaScript ces développeurs sont en minorité. Croisons les doigts pour que ça continue.

[SylvainPV]

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

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

[Paleo]

Je ne sais pas ce que tu appelles "code dynamique" et "code statique", jusqu'ici on parlait uniquement du typage. Et TypeScript apporte un typage statique optionnel, c'est revendiqué et plébiscité.

Pardon pour l'imprécision. Je parle bien du typage. Le typage en TS est plus proche de l'inférence et du JSDoc que d'un typage comme en Java. En Java, on ne peut pas prendre un objet (correspondant à un emplacement en RAM) et subitement faire comme si le type qui lui est associé avait changé. En TypeScript, on le fait, on manipule donc les types des objets dynamiquement. Ce qui n'est pas dynamique, c'est la définition des types, et cela ne change rien au typage dynamique et modifiable des variables (les emplacements mémoire).

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

[youtpout978]

Ce qui est un peut normal pour typescript vu que derrière ce qu'il génère c'est du JS.

[Paleo]

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

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

[SylvainPV]

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