[JS] Invoquer dynamiquement une methode sur une class

[niahoo]

Ah oui moi aussi j'attends toujours ce fameux benchmark http://www.jeuweb.org/showthread.php?tid...#pid119692

[Maks]

Il suffit de lire un peu plus loin que la page 8.

[niahoo]

arrêtes, le type fait que créer des objets ... forcément ça va plus vite. mais à ce compte là un vélo va plu vite qu'une ferrari parce qu'il se monte plus rapidement ?

[Xenos]

Ma foi, si tu trouves cela plus lisible. La perf', j'm'en fous si ca doit flinguer la lisibilité du code (et le jour où "class" sera vraiment utile, j'en chierais moins :p), surtout dans un cas avec peu d'objets.
Argorate ne veut pas du switch, donc ton code n'est pas la réponse à la question (ah làlà, la prépa où on apprend à répondre exactement à la question et pas à coté... c'est vieux tout ça, mais ça reste :roll: ).

GazXenon est destiné à être utilisé comme une classe, oui, d'où la majuscule.

(pour la dénomination, je n'ai pas "pNom" car cela donne des "pParamètre" qui deviennent peut agréable à lire, ou pire, "pparametre", puisqu'il s'agit d'une variable)

[Maks]

arrêtes, le type fait que créer des objets ... forcément ça va plus vite. mais à ce compte là un vélo va plu vite qu'une ferrari parce qu'il se monte plus rapidement ?

Je ne vois pas où tu veux en venir avec ton allégorie du vélo et de la Ferrari. Moi je préfère les chiffres. Si tu veux continuer à faire des closures ne te gêne pas ceci-dit je n'impose rien.

Ma foi, si tu trouves cela plus lisible. La perf', j'm'en fous si ca doit flinguer la lisibilité du code (et le jour où "class" sera vraiment utile, j'en chierais moins 10), surtout dans un cas avec peu d'objets.
Argorate ne veut pas du switch, donc ton code n'est pas la réponse à la question (ah làlà, la prépa où on apprend à répondre exactement à la question et pas à coté... c'est vieux tout ça, mais ça reste 38 ).

GazXenon est destiné à être utilisé comme une classe, oui, d'où la majuscule.

(pour la dénomination, je n'ai pas "pNom" car cela donne des "pParamètre" qui deviennent peut agréable à lire, ou pire, "pparametre", puisqu'il s'agit d'une variable)

C'est pas une question de lisibilité, c'est une question de pas pondre des codes crades.

J'ai bien lu la question (tu troll ou quoi ?), c'était pour coller à la Factory, je propose une solution alternative si tu avais fais l'effort de lire tout mon message.

Tu n'as rien compris à ma remarque sur les méthodes que tu prends pour des classes.

Si tu n'aimes pNom et le camelCase, il faut être cohérent et tout mettre en snake_case.

[Xenos]

Prouve-le moi que c'est "crade". Ok, niveau performances, c'est moins bon, ca d'accord, mais cela ne veut pas dire que le code lui-même est "crade", sinon, on écrirai tout en assembleur. Il faut un minimum de lisibilité, et je trouve les closures plus lisibles (d'autant qu'avec prototype, rien n'empêche d'éclater la déclaration des méthodes en une miriade de fichiers, alors qu'avec une closure, cela me semble franchement impossible de séparer la function-class sur deux fichiers différents).

Ce que je veux donc éviter c'est d'avoir à faire:

if(data.className == 'Character') new Charater(data);
else if(data.className == 'Mob') new Mob(data);
...

Ok, t'as fait un switch, mais c'est du même ressort
L'alternative est ok, mais Argorate ne semble pas chercher une "Factory propre", mais un moyen de ne pas se taper le switch ou les if à la main.

J'aime pas pNom à cause du fait que "p" est une abréviation. Et j'ai la flemme d'écrire "parametreNom" en toutes lettres, d'où ce "mixe" (au moins, on reconnait de suite mes codes si je suis le seul à faire ce genre de mixe :p)

[srm]

Argorate devrait se taper une Factory Propre :p

[Maks]

Je disais "crade" pour le code en général et la mauvaise maitrise des concepts Javascript.

function ListeGaz()

{

	this.GazXenon = function ()

	{

	}

}



new ListeGaz.GazXenon();

Ca ça ne se fait pas. Ecris comme tel c'est une classe ListeGaz qui a une méthode gazXenon en closure et qui devrait être appelée sous la forme new ListeGaz().gazXenon()

Si tu veux garder les closures avec un espace de nom tu peux faire :

var ListeGaz = {

  GazXenon: function() {



  };

};



new ListeGaz.GazXenon();

Et la solution pour les prototypes je l'ai donnée.

Pour coller à ce que veut Argorate on peut faire (comme je proposais en dernier) :

GasFactory.make = function(name) {

    if (GasList.hasOwnProperty(name)) {

        return new GasList[name];

    }

    else {

        throw new TypeError(name + " class does not exists");  

    }

};

De même on ne teste pas l'existence d'une clé en JS comme tu l'as fais

Et encore ce que je viens de mettre c'est pas terrible, car si tu passes "constructor" au param name, tu passeras bien dans le if s'il s'agit d'un objet. De mémoire c'est quelque chose comme Object.prototype.hasOwnProperty.call(GasList, name) la méthode "safe".

[Xenos]

Ahh, bien vu pour l'espace de nom. Ca m'était sorti de l'esprit. Du coup, oui, var ListeGaz = { Classe:function(){} } est bien plus agréable, il faudra que je m'en souvienne à l'avenir

Le test d'existence est un honteux copier-différer-coller de StackOverflow :heu:

Mais qu'en serait-il, avec "hasOwnProperty", si jamais GazList déclarait une variable et non une classe?
Par exemple, si j'utilise un "GasFactory.make('GasFailure')" avec:

var GasList = {

GasFailure: true;

};

? Le "new true()" ne va jamais passer :heu:

Edit: Apparemment répondu via Object.prototype.hasOwnProperty.call(GasList, name) qui devrait permettre de bien traiter ce cas du "GasFailure:true".

[niahoo]

Je te sortirai les chiffres quandcje reviens de congé si le topic court la je suis sur un tel. Par contre j'ai pas vu ou il y avait des closures mais bon comme j'ai l'air d'être le seul je suis content que vous tombiez d'accord