Discussion :

[domi65]

Avec des si, on en fait des choses !

Et ma question portait sur JS dans le cadre du web, le seul que je connaisse à vrai dire, et ce pour quoi il a été conçu. Donc les histoire de décalages de bit, je ne suis pas sûr que ce soit le soucis n°1 des développeurs.
Quant à dire que les créateurs du JS ne comprenaient pas ce qu'ils faisaient, c'est assez dédaigneux.

[Neckara]

Avec des si, on en fait des choses !

Dans l'optique où c'est un choix des navigateurs…

Et ma question portait sur JS dans le cadre du web, le seul que je connaisse à vrai dire […]

Java avec les applets, ActionScript pour flash, HTML5/CSS (turing compliant), XML/XSLT (turing compliant).

Et encore une fois, tout langage qui peut être trans-compilé via emscripten (e.g. C++).

Donc les histoire de décalages de bit, je ne suis pas sûr que ce soit le soucis n°1 des développeurs.

Pour peu que tu fasses, e.g., un peu de crypto côté client (hashs, chiffrer/déchiffrer, générateur aléatoire avec graine, etc.).

Et cela montre quand même un problème qui n'est pas des moindre au niveau même de la création du langage, et le fait qu'il faille se méfier de la moindre petite chose car cela se comporte "très bizarrement".

Quant à dire que les créateurs du JS ne comprenaient pas ce qu'ils faisaient, c'est assez dédaigneux.

Je ne connais pas beaucoup de langages aussi horrible.

Bon il est vrai que le ByteBuffer de Java est ridicule, que la gestion Java/Android est parfois trop idiot-proof, les références PHP un peu bizarres, mais rien qui n'aille au niveau de JavaScript, où les bases même de la logique sont piétinées.


Dans ce fil, on a eu aussi pas mal d'autres exemples d'horreurs en JavaScript.

[blbird]

Je ne parle même pas des "classes" JavaScripts introduites avec ES6, qui ne supportent même pas l'appel d'une méthode (non-statique) de la classe mère ! Cela devait être trop compliqué à implémenter..

Encore un parfait exemple de quelqu'un qui n'a rien compris aux fondements du JS, et qui se permet de critiquer sur des exemples précis qui ne lui conviennent pas, principalement parce que "ce n'est pas comme la majorité des autres langages OO" et/ou parce "c'est un langage de script". C'est désespérément puéril.

Par quel langage de script tu peux remplacer JS dans une page web ?
Quant à JS, il est détesté pour trois raisons :
- il est mal (voire très mal) compris
- On confond JS et interface DOM
- La mauvaise prise en charge des navigateurs du couple JS-DOM complique son l'utilisation pour le web.

Perso, la seule chose que j'aurais à reprocher à JS, c'est son typage.

Totalement d'accord avec toi.

A noter que l'idée de cryptage côté client fait aussi preuve d'une exceptionnelle connaissance du sujet. LOL !!!

[Uther]

Quant à dire que les créateurs du JS ne comprenaient pas ce qu'ils faisaient, c'est assez dédaigneux.

C'est pas dédaigneux mais un constat. Le JavaScript est bien connu pour avoir été créé en un temps record et intégré a toute vitesse dans Netscape a une époque ou c'était la course a la vitesse pour intégrer de nouvelle techno sans réfléchir vraiment si c'était une bonne idée ou pas. Parmi les autres joyeusetés de cette époque dont on a heureusement réussi a se débarrasser, il y a les balises "blink" et "marquee".

Le fait que JavaScript ne soit pas un langage fait pour les développements lourds coté client était assumé à l'époque. Pour les développement lourds, l'objectif était d'utiliser Java. Le succès de JavaScript est surtout la conséquence de l'échec des applets Java.

[Neckara]

Encore un parfait exemple de quelqu'un qui n'a rien compris aux fondements du JS, et qui se permet de critiquer sur des exemples précis qui ne lui conviennent pas, principalement parce que "ce n'est pas comme la majorité des autres langages OO" et/ou parce "c'est un langage de script". C'est désespérément puéril.

Je ne vois pas ce que vient faire le fait que ce soit un langage de script ici.


Ensuite me reprocher de "n'avoir rien compris aux fondements du JS"… c'est quand même assez facile…
Cela vous évite de répondre à la critique, et vous en profitez même pour ne pas nous dire en quoi je "n'[aurais] rien compris aux fondements du JS".

Un bon langage est un langage qui se doit d'être intuitif, et d'avoir le comportement qu'on attend de lui. Notamment en ce qui concerne l'héritage, et plus particulièrement le polymorphisme d'héritage, c'est l'une des bases de l'OO et une fonctionnalité importante.


Alors il doit bien y avoir un hack pour le faire, mais cela reste un hack. D'ailleurs peut-être as-tu un hack à nous proposer pour faire du polymorphisme d'héritage ?

A noter que l'idée de cryptage côté client fait aussi preuve d'une exceptionnelle connaissance du sujet. LOL !!!

Le "cryptage" n'existe pas, on dit "chiffrement".

Tu me reproches ironiquement de ne pas avoir une connaissance du sujet, c'est marrant car c'est exactement ce que je fais, ainsi que certains de mes collègues.

Pour des générateurs aléatoires seedables en JavaScript, c'est en effet tellement ridicule comme on peut le voir sur Google, de même pour les hashs. C'est tellement ridicule, qu'on a même des bibliothèques. Cela doit aussi être tellement stupide de faire du chiffrement/déchiffrement côté client pour stocker des informations côté serveur sans les exposer, e.g. serveurs de fichiers, serveurs de mails. Tellement stupide qu'on a même des extensions pour cela.

[Invité]

Ensuite me reprocher de "n'avoir rien compris aux fondements du JS"… c'est quand même assez facile…
Cela vous évite de répondre à la critique, et vous en profitez même pour ne pas nous dire en quoi je "n'[aurais] rien compris aux fondements du JS".

Un bon langage est un langage qui se doit d'être intuitif, et d'avoir le comportement qu'on attend de lui. Notamment en ce qui concerne l'héritage, et plus particulièrement le polymorphisme d'héritage, c'est l'une des bases de l'OO et une fonctionnalité importante.

En même temps, tu prouves toi-même que tu n'as pas compris les "fondements de JS". Ta description d'un "bon langage" semble correspondre à un choix de conception particulier (les langages OO basés classes, à la Java/C#/Python...). Il existe d'autres choix de conception de langages (OO à prototype, fonctionnels...) et tous ont leurs avantages et inconvénients. Quand on trouve qu'un langage est peu intuitif, c'est souvent qu'on n'a pas vraiment compris ses choix de conception. Après, on peut avoir une préférence sur les types de langage mais de là à les qualifier d'intuitif ou non...

Le "cryptage" n'existe pas, on dit "chiffrement".

Il n'y a pas vraiment consensus (https://fr.wiktionary.org/wiki/cryptage) et ce n'est peut-être pas le plus gros problème de la discussion.

Alors il doit bien y avoir un hack pour le faire, mais cela reste un hack. D'ailleurs peut-être as-tu un hack à nous proposer pour faire du polymorphisme d'héritage ?

Je connais l'héritage comme moyen de réaliser du polymorphisme mais je ne connais pas le "polymorphisme d'héritage". C'est un terme à toi ou j'ai raté un truc ?

[foetus]

Je connais l'héritage comme moyen de réaliser du polymorphisme mais je ne connais pas le "polymorphisme d'héritage". C'est un terme à toi ou j'ai raté un truc ?

Et explique moi tu es développeur - codeur - programmeur

Polymorphisme (<- lien wiki en français) ou sur cette page avec un schéma (<- lien wikibooks en français)

[Neckara]

En même temps, tu prouves toi-même que tu n'as pas compris les "fondements de JS".

En quoi ?

Ta description d'un "bon langage" semble correspondre à un choix de conception particulier (les langages OO basés classes, à la Java/C#/Python...). Il existe d'autres choix de conception de langages (OO à prototype, fonctionnels...) et tous ont leurs avantages et inconvénients.

Quand on propose des "class", avec des "extends", je suis désolé, mais si derrière on ne propose pas de l'OO avec le minimum de features qu'on retrouve dans les autres langages (dont le polymorphisme d'héritage), y'a un problème.

Quand on trouve qu'un langage est peu intuitif, c'est souvent qu'on n'a pas vraiment compris ses choix de conception.

Tu peux justifier tout et n'importe quoi derrière des "choix de conceptions", "c'est pas un bug, c'est une feature !".


Quand, e.g., le décalage de bit te sorts des résultats absurdes à cause d'un bit de signe qui se balade… tu m'expliques le choix de conception ?

Il n'y a pas vraiment consensus (https://fr.wiktionary.org/wiki/cryptage) […]

Le terme n’est pas mentionné dans le dictionnaire de l’Académie française^[7]. Dans le cadre de la télévision à péage, on parle quasi exclusivement de chaînes « cryptées », ce que l’Académie française accepte : « En résumé on chiffre les messages et on crypte les chaînes »^[8].

Je connais l'héritage comme moyen de réaliser du polymorphisme mais je ne connais pas le "polymorphisme d'héritage". C'est un terme à toi ou j'ai raté un truc ?

En gros, e.g. :

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
25
class A {

     constructor(){ this._a = 0; }

     foo() { return this.faa(); }
     faa() { return this.a; }
};

class B extends A {

     constructor(){ super(); }

      faa() { return A::faa() /* <- comment le faire en JavaScript ? */ + 1; }
};

B b;
A a;

function print(a) {
    console.log( a.foo() );
}

print(a); // 0
print(b); // 1

[melka one]

polymorphisme quelle beau mot qui me donne envie de fuir de plus j'ai déjà vu des conversations qui tendent a déglorifié cette pratique car elle a complexifier la poo en tout cas dans une conversation sa fait classe comme mot par contre ça risque de faire fuir les filles .

[Invité]

Et explique moi tu es développeur - codeur - programmeur

Polymorphisme (<- lien wiki en français) ou sur cette page avec un schéma (<- lien wikibooks en français)

Tu ne comprends même pas les liens que tu donnes : "concept consistant à fournir une interface unique à des entités pouvant avoir différents types". Le polymorphisme s'applique à des classes. L'héritage est un moyen de faire du polymorphisme (c'est aussi dans ton lien : "le polymorphisme peut être réalisé par différents moyens, inhérents au langage"). Donc le "polymorphisme d'héritage" ça voudrait dire qu'on peut faire différent types d'héritage avec des classes d'héritage...

Quand on propose des "class", avec des "extends", je suis désolé, mais si derrière on ne propose pas de l'OO avec le minimum de features qu'on retrouve dans les autres langages (dont le polymorphisme d'héritage), y'a un problème.

On peut faire des classes de types sans OO, ça s'appelle du polymorphisme paramétrique. Et c'est expliqué dans le lien précédent...

Tu peux justifier tout et n'importe quoi derrière des "choix de conceptions", "c'est pas un bug, c'est une feature !".

N'importe quoi. Java ne fait pas d'héritage multiple de classe donc c'est un bug ? Et tant qu'on y est un marteau c'est bien mais un tournevis c'est mal ?

[Neckara]

[…] Donc le "polymorphisme d'héritage" ça voudrait dire qu'on peut faire différent types d'héritage avec des classes d'héritage...

Donc tout ça, parce qu'on dit "polymorphisme d'héritage" au lieu de "polymorphisme par héritage" ?

On peut faire des classes de types sans OO, ça s'appelle du polymorphisme paramétrique. Et c'est expliqué dans le lien précédent...

Sauf que "extends", c'est quand même un peu de l'OO…
Mot clé qui est d'ailleurs utilisé en Java pour l'héritage.

N'importe quoi. Java ne fait pas d'héritage multiple de classe donc c'est un bug ? Et tant qu'on y est un marteau c'est bien mais un tournevis c'est mal ?

…

Premièrement, Java fait de l'héritage multiple par le biais des interfaces, avec lesquelles il est possible de définir des méthodes par défauts depuis Java 8. Bien que les créateurs de Java se soient aussi plantés en oubliant de définir des interfaces pour certaines classes de la bibliothèque standard.

Deuxièmement, il ne faut pas confondre un langage se voulant idiot-proof, évitant ainsi l'héritage en diamant, avec un langage qui implémente de l'OO qu'à moitié via un sucre syntaxique, sans offrir d'alternatives pour ce qui manque. Bien qu'il aurait été possible, pour Java, de faire comme C++ en utilisant de l'héritage virtuel.

Troisièmement, ce problème d'OO n'est qu'une des choses que je reproche au JavaScript, et notamment pour les décalages de bits, ça ressemble beaucoup plus à un bug, qu'à une feature.

Quatrièmement, le "ce n'est pas un bug, mais une feature" est un exemple de "justifier tout et n'importe quoi par des choix de conceptions", ce qui ne veut pas dire que je considère tout ce qui est justifié par des choix de conception comme étant un bug.

[Invité]

Donc tout ça, parce qu'on dit "polymorphisme d'héritage" au lieu de "polymorphisme par héritage" ?

Oui, désolé d'avoir perturbé le débat "cryptage" vs "chiffrement".

Sauf que "extends", c'est quand même un peu de l'OO…
Mot clé qui est d'ailleurs utilisé en Java pour l'héritage.

Encore une fois, JS est OO mais basé prototype et non basé classe. Et ce sont des "fondements" ou "choix de conception" très différents.

[Invité]

Code :

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

1
2
3
4
5
6
7
class B extends A {

     constructor(){ super(); }

      faa() { return A::faa() /* <- comment le faire en JavaScript ? */ + 1; }
};

j'oubliais...

Code :

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

1
2
3
4
5
6
7
8

class B extends A {

  constructor () { super(); }

  faa() { return A.prototype.faa.call(this) + 1; }
}

[foetus]

SimonDecoline qui clame haut et fort "JS == prototype" et qui nous sort du TypeScript/ ECMAScript 7

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
var A = {
    name: 'A',
    constructor: function() { /**/ },
    faa: function() { /**/ return this.name; }
};

// Inherit
//var B = Object.create(A, {
//  name: {value: 'B'}
//});

// Alternative
var B = {
    name: 'B',
    __proto__: A
};

B.constructor  = function() {
    this.__proto__.constructor(); 
}

B.faa = function() {
    return (this.__proto__.faa() + 1); // <- "A1", JavaScript is magic :-)
}

[Neckara]

j'oubliais...

Code :

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

1
2
3
4
5
6
7
8
class B extends A {

  constructor () { super(); }

  faa() { return A.prototype.faa.call(this) + 1; }
}

C'est marrant, j'aurais pourtant juré que ça ne marchait que pour les méthodes statiques, ce n'est pas faute d'avoir essayé pendant quelques heures à l'époque.

Alors est-ce que je n'avais pas les yeux en face des trous, est-ce que j'ai tenté des choses similaires mais pas exactement cela, est-ce que Firefox le supportait mal dans ses anciennes versions ? Je me retrouve quand même un peu con.


En tout cas, je ne peux que te remercier sur ce point là.

Encore une fois, JS est OO mais basé prototype et non basé classe. Et ce sont des "fondements" ou "choix de conception" très différents.

Ben dans l'optique où ce que je reprochais (en ce qui concerne l'OO) marche… mais critique disparaît sur cet aspect.


Mais je ne suis pas en reste de critiques :

Code :

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

1
2
3
4
5
6
7
console.log(1<<32) // 1
console.log( (1<<31) << 1) // 0
 console.log( ((1<<31) >>> 0) << 1) // 0

console.log( ((1 << 31) >>> 0).toString(16) ) // 80000000
console.log( (1 << 31).toString(16) ) // -80000000

En gros "décaler" un bit 32 fois ne donne pas le même résultat que de le "décaler" 31 fois, puis de le "décaler" 1 fois.
C'est aussi choquant que si :
1 + 1 + 1 != 1+2 ou
'a' + 'b' + 'c' != 'a' + 'bc'.

[Invité]

SimonDecoline qui clame haut et fort "JS == prototype" et qui nous sort du TypeScript/ ECMAScript 7

Mais bien sûr...

"JavaScript classes, introduced in ECMAScript 2015, are primarily syntactical sugar over JavaScript's existing prototype-based inheritance. The class syntax does not introduce a new object-oriented inheritance model to JavaScript."
https://developer.mozilla.org/en-US/...erence/Classes

Et c'était pour reprendre l'exemple de code donné initialement.

[edit] Et ton code ne fonctionne pas : il affiche "A11" et non "A1".

Code :

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

1
2
3
4
B.faa = function() {
    return (A.faa(this) + 1); 
}

[Invité]

En tout cas, je ne peux que te remercier sur ce point là.

Mais de rien.

Mais je ne suis pas en reste de critiques :
...

Oui, JS est critiquable sur pas mal de points. Dans le genre, il y a aussi le "null" qui est un objet, donc pas vraiment nul...

"You can consider it a bug in JavaScript that typeof null is an object. It should be null."
https://www.w3schools.com/js/js_datatypes.asp

[foetus]

"JavaScript classes, introduced in ECMAScript 2015, are primarily syntactical sugar over JavaScript's existing prototype-based inheritance. The class syntax does not introduce a new object-oriented inheritance model to JavaScript."

Justement montre nous les vrais objets JavaScript qui sont des tableaux associatifs.

Et ensuite, je ne pense pas que ce soit que du sucre syntaxique : parce qu'il initialise à la fois la chaîne de prototypes et crée un constructeur automatique.

[edit] Et ton code ne fonctionne pas : il affiche "A11" et non "A1".

je l'ai testé et il fonctionnait.
Mais moi je n'appelle pas avec le "call(this)" : et donc cela va dépendre fortement de comment tu appelles la méthode.
Et effectivement on peut appeler directement l'objet parent (puisqu'il n'y a pas de classes, mais des prototypes)

[SylvainPV]

Code :

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

1
2
3
4
5
6
7
class B extends A {

     constructor(){ super(); }

      faa() { return A::faa() /* <- comment le faire en JavaScript ? */ + 1; }
};

return super.faa() + 1
https://developer.mozilla.org/fr/doc...9rateurs/super

[Neckara]

C'était l'une des premières choses que j'avais essayé à l'époque.

Je présume que j'avais dû les essayer avec une erreur dans le nom de la méthode, puis lorsque que j'ai corrigé l'erreur dans le nom, j'ai dû tenter d'autres choses sans réessayer les premières solutions (qui marchaient donc). Toujours est-il que je me sens vraiment con actuellement.