C'est quand même assez limité lorsqu'on veut un peu optimiser les choses.
Si j'osais, je dirais que c'est comme si on filait un pistolet à billes à un soldat.
Par exemple, définir des fonctions dans le constructeur (le concept de membre privilégié dans le texte de ce bon vieux Douglas Crockford) est une mauvaise pratique car elle instancie une méthode par instance d'objet, au lieu de la définir dans le prototype.
Pareil pour le concept de membres privés, lorsqu'on souhaite définir les fonctions dans prototype, ces fonctions ne peuvent naturellement plus accéder aux variables du scope du constructeur, donc pour mutualiser des données entre les fonctions du prototype, on est forcé de les déclarer dans l'objet ou dans son prototype (public).
Cela dit, j'ai pleinement pris le parti de faire comme tu disais et d'assumer pleinement les manques du langage ; je fais du private par convention, dans la documentation, et tant pis pour ceux qui passent outre. Ca a quand même des effets assez horribles, moi je m'en fous, je fais du code métier, si quelqu'un utilise des membres privés de mon code, ça sera un collègue et on peut s'arranger, mais on utilise un framework javascript connu (extjs), et lorsqu'elle possède certains manques fonctionnels, on est très tenté d'aller hériter ou écraser une méthode privée au lieu d'attendre sagement une prochaine révision du framework. Oui, c'est mal, mais j'ai remarqué qu'on était loin d'être les seuls, du coup, je plains un peu Sencha pour gérer la réorganisation de son code privé au regard de sa clientèle qui paniquera le jour où plus rien ne marche à une révision mineure supérieur :) Du coup, on met de gros warnings dans le code les quelques fois où on est poussé à le faire.
[^] # Re: Lua
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 5. Dernière modification le 07 février 2013 à 08:05.
C'est quand même assez limité lorsqu'on veut un peu optimiser les choses.
Si j'osais, je dirais que c'est comme si on filait un pistolet à billes à un soldat.
Par exemple, définir des fonctions dans le constructeur (le concept de membre privilégié dans le texte de ce bon vieux Douglas Crockford) est une mauvaise pratique car elle instancie une méthode par instance d'objet, au lieu de la définir dans le prototype.
Pareil pour le concept de membres privés, lorsqu'on souhaite définir les fonctions dans prototype, ces fonctions ne peuvent naturellement plus accéder aux variables du scope du constructeur, donc pour mutualiser des données entre les fonctions du prototype, on est forcé de les déclarer dans l'objet ou dans son prototype (public).
Cela dit, j'ai pleinement pris le parti de faire comme tu disais et d'assumer pleinement les manques du langage ; je fais du private par convention, dans la documentation, et tant pis pour ceux qui passent outre. Ca a quand même des effets assez horribles, moi je m'en fous, je fais du code métier, si quelqu'un utilise des membres privés de mon code, ça sera un collègue et on peut s'arranger, mais on utilise un framework javascript connu (extjs), et lorsqu'elle possède certains manques fonctionnels, on est très tenté d'aller hériter ou écraser une méthode privée au lieu d'attendre sagement une prochaine révision du framework. Oui, c'est mal, mais j'ai remarqué qu'on était loin d'être les seuls, du coup, je plains un peu Sencha pour gérer la réorganisation de son code privé au regard de sa clientèle qui paniquera le jour où plus rien ne marche à une révision mineure supérieur :) Du coup, on met de gros warnings dans le code les quelques fois où on est poussé à le faire.