Propriétés privées en JavaScript

**Beginner.** · 05/04/2018, 20h01

Si je veux une propiété privée, je fais comment ?

J'ai essayé ç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
25
26
27
28
29
30
var Car = Object.create(Object.prototype);
Car.wheels = 4;
Car.drive = function () {
    this.speed = 120;
};
 
Car.create = function (constructor, model) {
 
    var prix = 100;
 
    return Object.create(Car, {
        constructor: {
            writable: true,
            configurable: true,
            value: constructor
        },
        model: {
            writable: true,
            configurable: true,
            value: model
        },
 
        getPrix: function () {
            console.log("le prix est : ", prix);
        }
    });
};
 
var volvo = Car.create("Volvo", "S60");
volvo.getPrix();

Mais ça marche pas...

**SylvainPV** · 05/04/2018, 20h53

Le concept de propriété privée n'existe pas en JavaScript, mais une proposal est à l'étude (https://github.com/tc39/proposal-cla...private-fields). En attendant, ce qui s'en rapproche vaguement est de rendre la propriété non énumérable.

**Beginner.** · 05/04/2018, 21h05

Pour les propriétés privées on en parlait (j’espère ne pas avoir dit de bêtises) justement ici :Analyse de 'Classes'....

J'ai vu pleins de chapitres de bouquins qui proposent des solutions pour ça...

**SylvainPV** · 05/04/2018, 21h50

Ce que tu suggères dans l'autre topic n'est pas une propriété privée mais une variable locale. Une propriété privée n'est visible et accessible que par son propriétaire (c'est à dire pour la prog objet par classe, le constructeur et les méthodes d'une classe). On parle bien de "propriété" ou "membre" privé et non de variable, car une propriété est privée au regard d'une classe, tandis qu'une variable est locale par rapport à un scope (la "portée" de la variable) et n'est pas rattachée à un objet parent, donc inutilisable dans une autre méthode par exemple.

Il existe bien des solutions pour se rapprocher du comportement de propriété privée, par exemple en employant les Proxy et en vérifiant la valeur du mot-clé "this" avant d'autoriser l'accès à une propriété. C'est ce que j'ai fait avec ma bilbiothèque ObjectModel: http://objectmodel.js.org/#doc-private-and-constants ; mais ça ne fait pas partie du design du langage et l'intérêt des propriétés privées est très discutable en soi... mais il y a là de quoi ouvrir un tout nouveau débat.

**Beginner.** · 06/04/2018, 19h05

Pour les propriétés privées/publics je pensais entre autres à cette exemple de code commenté (source #10) :

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
var monProgramme = (function () {
  // déclaration de toutes les variables utilisées
  var maVar, maFonction; 
 
  // Remplir les variables
  maVar = "je suis privée et ne pollue pas";
  maFonction = function maFonction() {
    console.log("On ne peut pas m'appeler avec maFonction() de l'extérieur du module. Seulement avec log()");
  }
 
 // Retourne un objet ouvert au public qui contient ce qui doit l'être
 return {
   // setter qui permet de changer la valeur de maVar
   setMaVar: function setMaVar(valeur){
     maVar = valeur;
   },
 
   // getter qui permet de récupérer la valeur de maVar
   getMaVar: function getMaVar(){
     return maVar;
   },
 
   // Fonction Publique qui appelle une privée
   log: function log() {
     maFonction();
   }
 };
 
})();
 
console.log(monProgramme.getMaVar()); // "je suis privée et ne pollue pas"
console.log(monProgramme.maVar); // undefined car n'est pas présente dans l'objet rendu public
monProgramme.maVar = 'toto'; // modification de l'objet rendu public qui n'a rien à voir avec l'autre maVar
console.log(monProgramme.getMaVar()); // toujours "je suis privée et ne pollue pas"
monProgramme.setMaVar("on me change de l'extérieur car c'est permis !");
console.log(monProgramme.getMaVar()); // "on me change de l'extérieur car c'est permis !"

On voit aussi qu'avec une IIFE on peut fabriquer des objets alors je pose la même question que ma question 1 mais pour les IIFE...

Il y a aussi plusieurs livres, articles, tutos qui en parlent plus ou moins de cette manière...

Merci.

**SylvainPV** · 06/04/2018, 21h11

Même chose, maVar et maFonction sont des variables locales, pas des propriétés privées puisque ce ne sont pas des propriétés, elles n'appartiennent pas à un objet. Si on déclare a posteriori d'autres méthodes sur cet objet, elles ne pourront pas accéder à ces variables car on ne sera plus dans le même scope. Inversement, ces variables sont accessibles depuis n'importe quel code à l'intérieur de l'IIFE, même si ce code n'a rien à voir avec l'objet retourné.

Se servir d'une IIFE pour déclarer des variables sans polluer le scope extérieur est un pattern très utile, mais on ne peut pas appeler ça des propriétés privées, ni même des propriétés tout court.

**grunk** · 07/04/2018, 08h59

Aujourd'hui la solution la plus simple est de passer par un transpiler du genre de typescript qui va "émuler" les propriétés privées au moment de la transpilation.

Tu peux alors écrire quelque chose comme :

Code :

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

1
2
3
4
5
6
class Animal {
    private name: string;
    constructor(theName: string) { this.name = theName; }
}
 
new Animal("Cat").name; // Error: 'name' is private;

**SylvainPV** · 07/04/2018, 12h34

A noter que le caractère privé des propriétés TypeScript est seulement assuré par son compilateur. Dans le code JavaScript généré, ce sont des propriétés normales qu'il est facile de récupérer:

Code typescript :

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

1
2
3
4
5
6
7
8
 
class Animal {
    private name: string;
    constructor(theName: string) { this.name = theName; }
}
 
 
alert(new Animal("Cat")['name']);

**Beginner.** · 07/04/2018, 19h38

Salut,

Ok je précise (pour les autres) que ce sujet vient d'un autre fil (il y a eu un déplacement)...

Envoyé par SylvainPV

Ce que tu suggères dans l'autre topic n'est pas une propriété privée mais une variable locale. Une propriété privée n'est visible et accessible que par son propriétaire (c'est à dire pour la prog objet par classe, le constructeur et les méthodes d'une classe). On parle bien de "propriété" ou "membre" privé et non de variable, car une propriété est privée au regard d'une classe, tandis qu'une variable est locale par rapport à un scope (la "portée" de la variable) et n'est pas rattachée à un objet parent, donc inutilisable dans une autre méthode par exemple.

Oui ce ne sont pas des propriétés, parlons de données privées/publiques dans ce cas, c'est mieux ?

Ceci dit dans ce passage (de l'autre fil dont tu parles) :

Envoyé par Beginner.

En tant que débutant un peu perdu (te voilà prévenu) et vu que tu viens du C/C++ je dirais que c'est une méthode privée : si tu crées une instance de ClassName celle-ci n’aura pas accès à la méthode thirdFunction par contre elle aura accès aux méthodes firstMethod, secondMethod...

Je dis méthode privée or une méthode en JS (si j'ai bien compris) c'est une propriété dont la valeur est une fonction du coup est-ce aussi incorrecte de parler de méthode privée ? Et qu'en est-il de "variables/méthodes" privées ou même de "membres privés" ?

En tous cas j'ai vu certains*** utiliser des expressions comme "private/public members", "private/public methods", "private instance variables"... Et ça concerne aussi bien les variables que les fonctions...

*** Même l'auteur que tu cites dans l'autre fil (sur Object.create) à savoir Douglas Crockford dans ce lien par exemple : Private Members in JavaScript ... Il écrit même "Private members are made by the constructor. Ordinary vars and parameters of the constructor become the private members."...

Ainsi si je comprends bien les variables (locales) et les paramètres du constructeur deviennent des membres privés...

Il va même jusqu'à dire qu'ils sont attachés à l'objet :

Code javascript :

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

1
2
3
4
5
function Container(param) {
        this.member = param;
        var secret = 3;
        var that = this;
    }

This constructor makes three private instance variables: param, secret, and that. They are attached to the object, but they are not accessible to the outside, nor are they accessible to the object's own public methods. They are accessible to private methods. Private methods are inner functions of the constructor.

Je cite un autre passage où il semble répondre à ceux qui prétendent que les objets JS ne peuvent pas avoir de variables/méthodes privées :

Some argue that JavaScript is not truly object oriented because it does not provide information hiding. That is, objects cannot have private variables and private methods: All members are public.

But it turns out that JavaScript objects can have private variables and private methods. (Click here now to find out how.) Of course, few understand this because JavaScript is the world's most misunderstood programming language.

Source :JavaScript: The World’s Most Misunderstood Programming Language.

----> Il y a là aussi de quoi s'y perdre décidément il faut faire attention à beaucoup de choses en JS...

-----------------

Envoyé par SylvainPV

Il existe bien des solutions pour se rapprocher du comportement de propriété privée, par exemple en employant les Proxy et en vérifiant la valeur du mot-clé "this" avant d'autoriser l'accès à une propriété. C'est ce que j'ai fait avec ma bilbiothèque ObjectModel: http://objectmodel.js.org/#doc-private-and-constants ; mais ça ne fait pas partie du design du langage et l'intérêt des propriétés privées est très discutable en soi... mais il y a là de quoi ouvrir un tout nouveau débat.

Ah je me souviens que tu avais ouvert un fil à propos de cette bibliothèque, il faudrait que je regarde de nouveau pour voir si je comprends plus de choses qu'à l'époque...

Envoyé par grunk

Aujourd'hui la solution la plus simple est de passer par un transpiler du genre de typescript qui va "émuler" les propriétés privées au moment de la transpilation.

Tu peux alors écrire quelque chose comme :

Code :

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

1
2
3
4
5
6
class Animal {
    private name: string;
    constructor(theName: string) { this.name = theName; }
}
 
new Animal("Cat").name; // Error: 'name' is private;

Merci pour cet exemple, je vais regarder de plus prés...

**SylvainPV** · 08/04/2018, 12h52

Pour se mettre au clair sur le vocabulaire:
variable = référence à une donnée accessible en lecture/écriture
propriété = variable rattachée à un objet par une référence
membre = synonyme de propriété, surtout utilisé par les anglophones
méthode = propriété de type fonction

L'adjectif "privé" implique que l'on parle d'une propriété par définition, si ce n'est pas une propriété alors il n'a pas de propriétaire et n'est donc privé au regard de rien du tout.

Donc méthode privée oui, mais donnée privée ne veut pas dire grand chose. Une même donnée peut avoir plusieurs références, qui peuvent être des propriétés ou non, privées ou non.

**Watilin** · 08/04/2018, 17h37

Envoyé par Beginner.

*** Même l'auteur que tu cites dans l'autre fil (sur Object.create) à savoir Douglas Crockford dans ce lien par exemple : Private Members in JavaScript ... Il écrit même "Private members are made by the constructor. Ordinary vars and parameters of the constructor become the private members."...
¨
Ainsi si je comprends bien les variables (locales) et les paramètres du constructeur deviennent des membres privés...

Douglas Crockford fait un peu un abus de langage ici. Si c’était une vraie propriété privée, on y accèderait en écrivant monObjet.propPrivee ; et selon le contexte, le compilateur nous autoriserait l’accès à cette propriété ou non.
Mais, dans sa conception, JS n’est pas un langage compilé. Il a des compilateurs aujourd’hui qui améliorent la performance des scripts, mais ces compilateurs ne sont pas des outils de développement, et en aucun cas ne vont refuser de travailler s’il y a une erreur dans le code source.

De plus, les fonctions de JS ont une nature dynamique (on peut les manipuler comme des variables) qui empêche de déterminer le contexte avant l’exécution. Ainsi, impossible de dire à quelle moment une « propriété privée » devrait être accessible ou non.

Il va même jusqu'à dire qu'ils sont attachés à l'objet :

Il a raison, en quelque sorte : puisqu’il y a une référence qui « sort » du constructeur, à savoir l’objet construit, cela entraîne la création d’une fermeture (closure) sur la portée locale du constructeur. Chaque appel à la fonction produit une fermeture différente ; et chaque même appel à la fonction crée une nouvelle instance (quand on n’oublie pas le mot-clé new). Il est donc correct de dire que la fermeture, et avec elle les variables locales du constructeur, sont rattachées à l’instance.

Une pensée plus générale : il est tout à fait légitime de vouloir des variables cachées, au nom du principe d’encapsulation qui est à la base de quasiment toutes les méthodes de conception orientée objet. Mais vouloir que ça ait exactement la même syntaxe que dans tel autre langage, c’est demander à JavaScript qu’il arrête d’être JavaScript, ça n’a pas vraiment de sens.

**SylvainPV** · 08/04/2018, 17h58

J'aime bien le nom "variables cachées", ça décrit beaucoup mieux ce dont il est question.

Pour info, je laisse ces liens assez complets qui listent les astuces ES5 et ES6 pour cacher de l'information:
http://2ality.com/2016/01/private-data-classes.html
http://speakingjs.com/es5/ch17.html#...ta_for_objects

Aucune de ces techniques n'apporte réellement de "propriétés privées", pour cela il faudra attendre la proposal dont j'ai posté le lien plus haut. Mais ça peut répondre à des besoins ponctuels.

**Beginner.** · 08/04/2018, 20h07

Salut,
Merci à vous deux pour vos réponses...

Vos réponses me confirment que c'est la jungle pour un débutant, difficile de s'y retrouver, le débutant doit faire attention et se méfier de beaucoup de choses, il ne peut pas se fier même aux développeurs auteurs de livres plus ou moins connus. Attention je ne dis pas que vous avez tort (je pense même que vous avez raison) mais la réalité c'est que toute cette terminologie est utilisée même dans des livres qui sont considérés parfois comme des références...

Et dire que Douglas Crockford a écrit un article intitulé "Javascript : le langage de programmation le plus incompris du monde", apparemment lui aussi il n'aurait pas compris certaines choses concernant ce langage ???

Envoyé par SylvainPV

Donc méthode privée oui, mais donnée privée ne veut pas dire grand chose.

Je proposais "donnée privée" à cause justement de l'article et du chapitre d'un livre dont tu as donnés les liens...
---> Oui en effet l'auteur Axel Rauschmayer utilise bien les termes "private data" et même "private properties"...

Envoyé par SylvainPV

membre = synonyme de propriété, surtout utilisé par les anglophones

Ok c'est bien ce que j'avais compris mais là où je voulais en venir c'est que du coup logiquement "membre privé" devrait être tout aussi incorrecte que "propriété privée" même si ces deux expressions sont utilisés par des auteurs.

Envoyé par SylvainPV

méthode = propriété de type fonction

Oui là aussi c'est bien ce que j'avais compris sauf que je l'ai exprimé différemment : "...c'est une propriété dont la valeur est une fonction...". Du coup puisque c'est une propriété il devrait logiquement être aussi incorrecte de parler de méthode privée ??? Mais là aussi c'est une expression très répandue...

Envoyé par SylvainPV

L'adjectif "privé" implique que l'on parle d'une propriété par définition, si ce n'est pas une propriété alors il n'a pas de propriétaire et n'est donc privé au regard de rien du tout.

Donc on ne devrait pas non plus employer cet adjectif ?

Envoyé par SylvainPV

Pour se mettre au clair sur le vocabulaire:

Ca va être difficile comme on vient de le voir car le mal est fait : le "mauvais vocabulaire" est déjà bien répandu même par des auteurs connus... Ainsi si tu t’adresses à des personnes qui se sont formés directement avec ces auteurs (leurs livres, articles, sites, vidéos...) ou indirectement avec des personnes (enseignants ou autres) qui eux mêmes ont appris avec ces auteurs eh bien tu auras du mal à te faire comprendre sans faire le lien entre ton vocabulaire et celui auquel ils sont habitués...

Genre tu diras des choses comme "Ce que j'entends par X c'est ce que tel auteur a expliqué (à tord) de la manière suivante : bla bla bla...".

Mais bon pour ma part, notamment en discutant avec vous, je pense avoir compris certaines choses et j’espère que ça va continuer...

Merci.

**Beginner.** · 08/04/2018, 20h37

Envoyé par Watilin

Douglas Crockford fait un peu un abus de langage ici. Si c’était une vraie propriété privée, on y accèderait en écrivant monObjet.propPrivee ; et selon le contexte, le compilateur nous autoriserait l’accès à cette propriété ou non.

Ben justement non, c'est justement le but, l'objet est censé ne pas avoir accès aux "propriétés privées" en tous cas pas directement (mais éventuellement indirectement via une "méthode publique" ou une "méthode privilégiée")... L'exemple de code commenté de Kaamo que j'ai déjà posté montre bien ce qu'il faut entendre par ceux qui emploi cette terminologie en JS (source #10) :

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
var monProgramme = (function () {
   // déclaration de toutes les variables utilisées
   var maVar, maFonction;  
 
   // Remplir les variables
   maVar = "je suis privée et ne pollue pas";
   maFonction = function maFonction() {
     console.log("On ne peut pas m'appeler avec maFonction() de l'extérieur du module. Seulement avec log()");
   }
 
  // Retourne un objet ouvert au public qui contient ce qui doit l'être
  return {
    // setter qui permet de changer la valeur de maVar
    setMaVar: function setMaVar(valeur){
      maVar = valeur;
    },
 
    // getter qui permet de récupérer la valeur de maVar
    getMaVar: function getMaVar(){
      return maVar;
    },
 
    // Fonction Publique qui appelle une privée
    log: function log() {
      maFonction();
    }
  };
 
 })();
 
 console.log(monProgramme.getMaVar()); // "je suis privée et ne pollue pas"
 console.log(monProgramme.maVar); // undefined car n'est pas présente dans l'objet rendu public
 monProgramme.maVar = 'toto'; // modification de l'objet rendu public qui n'a rien à voir avec l'autre maVar
 console.log(monProgramme.getMaVar()); // toujours "je suis privée et ne pollue pas"
 monProgramme.setMaVar("on me change de l'extérieur car c'est permis !");
 console.log(monProgramme.getMaVar()); // "on me change de l'extérieur car c'est permis !"

Voici aussi ci-dessous deux passages du fameux livre "JavaScript: Gardez le meilleur !" de Douglas Crockford... Je poste le premier passage pour l'explication mais j’avais aussi mis en surbrillance certains passages pour montrer que là il utilise carrément l’expression "propriété privée" :

En particulier la phrase "Il crée un objet avec une méthode get_status et une propriété privée status" est vraiment étonnante car il me semble que si il est vrai que la méthode get_status est une propriété de l'objet retourné par la fonction quo eh bien ce n'est pas le cas de status. Et un peu plus loin on a : "La méthode get_status possède toujours un accès privilégié à la propriété status de quo..." donc pour lui status appartient à qui ? A l'objet retourné par la fonction quo ou à fonction quo ? Ce n'est pas clair...

Le deuxième passage :

Envoyé par Watilin

Il a raison, en quelque sorte : puisqu’il y a une référence qui « sort » du constructeur, à savoir l’objet construit, cela entraîne la création d’une fermeture (closure) sur la portée locale du constructeur. Chaque appel à la fonction produit une fermeture différente ; et chaque même appel à la fonction crée une nouvelle instance (quand on n’oublie pas le mot-clé [FONT=monospace]new[/FONT]). Il est donc correct de dire que la fermeture, et avec elle les variables locales du constructeur, sont rattachées à l’instance.

Merci pour l'explication qui si j'ai bien compris correspond à ce que j'ai lu en anglais dans le deuxième lien posté par Sylvain :

Private Data in the Environment of a Constructor (Crockford Privacy Pattern)

When a constructor is invoked, two things are created: the constructor’s instance and an environment (see Environments: Managing Variables). The instance is to be initialized by the constructor. The environment holds the constructor’s parameters and local variables. Every function (which includes methods) created inside the constructor will retain a reference to the environment—the environment in which it was created. Thanks to that reference, it will always have access to the environment, even after the constructor is finished. This combination of function and environment is called a closure (Closures: Functions Stay Connected to Their Birth Scopes). The constructor’s environment is thus data storage that is independent of the instance and related to it only because the two are created at the same time. To properly connect them, we must have functions that live in both worlds. Using Douglas Crockford’s terminology, an instance can have three kinds of values associated with it (see Figure 17-4):

Merci.

**Watilin** · 08/04/2018, 21h08

Je soutiens que c’est un abus de langage, que tout le monde fait certes, et qui est tolérable.

En fait, c’est précisément parce qu’on n’a pas mécanisme exact de membres privés des langages à classes, qu’on peut se permettre de prendre ce qui s’en rapproche le plus et de lui donner ce nom. On ne va pas jeter l’eau du bain avec la peau de l’ours, c’est une approximation acceptable.

Dans mon post précédent j’ai fait la distinction entre JS et les langages statiques. J’ai été un peu trop vite : PHP par exemple, a des membres privés et pourtant c’est un langage dynamique. Ce qui fait la différence, en réalité, c’est le fait que PHP repose non pas sur des protoypes comme JS, mais sur des classes.

**SylvainPV** · 08/04/2018, 22h41

Essaye de garder 1 topic = 1 sujet s'il te plaît. C'est déjà assez difficile à suivre comme ça, pas la peine de relancer 5 questions qui n'ont rien à voir avec le sujet d'origine (que j'ai déjà découpé d'un sujet précédent, pour rappel).

Envoyé par Beginner

du coup logiquement "membre privé" devrait être tout aussi incorrecte que "propriété privée" même si ces deux expressions sont utilisés par des auteurs.
Du coup puisque c'est une propriété il devrait logiquement être aussi incorrecte de parler de méthode privée ??? Mais là aussi c'est une expression très répandue...
Donc on ne devrait pas non plus employer cet adjectif ?

Pour être clair, parce que j'ai beaucoup de mal à te suivre des fois: ces termes sont corrects, je les ai moi-même employés une bonne quinzaine de fois dans mes messages précédents. En revanche, l'usage de ces termes pour décrire les patterns de Crockford est clairement un abus de langage ; mais un abus de langage nécessaire pour mettre sur la piste les gens qui comme toi cherchent à reproduire en JavaScript des concepts qu'ils ont appris d'autres langages.

**Beginner.** · 09/04/2018, 00h07

Envoyé par SylvainPV

Essaye de garder 1 topic = 1 sujet s'il te plaît. C'est déjà assez difficile à suivre comme ça, pas la peine de relancer 5 questions qui n'ont rien à voir avec le sujet d'origine (que j'ai déjà découpé d'un sujet précédent, pour rappel).

Ben en fait suite à un rappel cordiale de la modération en privé j'ai promis de ne plus intervenir dans les deux fils : L'opérateur new, bonne ou mauvaise pratique ? [Tutoriel] et Analyse de 'Classes'.

Mais par contre je croyais que je pouvais "discuter" dans mes fils...

Enfin bref...

Envoyé par SylvainPV

Pour être clair, parce que j'ai beaucoup de mal à te suivre des fois: ces termes sont corrects,...

Oui je comprend et c'est d'ailleurs pareil pour moi...

Oui tu as employé toi-même ces termes mais justement j'y vois une contradiction...

Je ne sais pas comment être plus clair, peut-être en utilisant un pseudo langage ? Alors essayons en reprenant juste un exemple :

1- "propriété privé" === pas bon, mauvais, ça n’existe pas, c'est incorrecte... Ok là je pense qu'on a compris.
2- membre === propriété (synonyme)

3- 1 + 2 ----> "propriété privé" === "membre privé"

donc j'en ai déduit que "membre privé" devrait avoir le même statut que "propriété privé"...

Je ne sais pas si il y a une syntaxe error, il n'y a pas de F12 pour ça... Je plaisante... Un peu d'humour...

Bon aller j’arrête... Ça me fatigue aussi de me répéter...

**SylvainPV** · 09/04/2018, 12h01

Envoyé par SylvainPV

On parle bien de "propriété" ou "membre" privé et non de variable
L'adjectif "privé" implique que l'on parle d'une propriété par définition,
ces termes sont corrects, je les ai moi-même employés une bonne quinzaine de fois dans mes messages précédents.

Envoyé par Beginner

1- "propriété privé" === pas bon, mauvais, ça n’existe pas, c'est incorrecte... Ok là je pense qu'on a compris.

Je pense justement que tu n'as pas compris

**grunk** · 12/04/2018, 17h04

Envoyé par SylvainPV

J'aime bien le nom "variables cachées", ça décrit beaucoup mieux ce dont il est question.

Pour info, je laisse ces liens assez complets qui listent les astuces ES5 et ES6 pour cacher de l'information:
http://2ality.com/2016/01/private-data-classes.html
http://speakingjs.com/es5/ch17.html#...ta_for_objects

Aucune de ces techniques n'apporte réellement de "propriétés privées", pour cela il faudra attendre la proposal dont j'ai posté le lien plus haut. Mais ça peut répondre à des besoins ponctuels.

J'ai du mal à comprendre ce besoin de "bricoler" pour substituer une fonctionnalité absente du langage.
Le JS ne permet pas nativement d'avoir de propriété privée , et bien on fait avec.
La moins pire reste selon moi une convention de nommage qui ne rajoute pas de code est qui est globalement bien assimilé par tout le monde.

Et pour les gens comme moi qui n'arrivent pas à se plier au paradigmes de JS il reste les transpilers qui permettent de travailler comme avec des langages plus "classique". Faut juste pas être trop regardant sur le code généré

**SylvainPV** · 12/04/2018, 18h57

Ce n'est pas forcément du bricolage ; même si ce ne sont pas des propriétés privées, on peut vouloir jouer avec les scopes de cette façon dans un but précis.
Mais je te rejoins sur le fait que vouloir ramener toutes les features de son langage favori dans JavaScript n'a pas beaucoup de sens, déjà que JS est considéré par beaucoup comme un pot pourri...
Pour moi, le maigre besoin que représente les propriétés privées a été entièrement comblé avec les modules ES6, où l'on choisit ce que l'on veut exporter.

Propriétés privées en JavaScript

JavaScript

Discussions similaires

Partager

Partager