Je me pose la question suivante : quelle est la v=E9ritable contrainte qu=
i=20
obligerait =E0 utiliser des parenth=E8ses, lorsqu'on cr=E9e un nouvel obj=
et=20
alors que le constructeur ne pr=E9voie pas de passage d'arguments ?
Exemple :
<script>
function MyObj() {
this.myProp1 =3D "Hello";
this.myProp2 =3D " World!";
}
var newObj1 =3D new MyObj();
var newObj2 =3D new MyObj;
alert(newObj1.myProp1 + newObj2.myProp2): // Hello World!
</script>
Curieusement, je n'ai trouv=E9 aucune doc ni tuto qui oserait proposer la=
=20
deuxi=E8me syntaxe. Pourtant, si elle est tol=E9r=E9e par tous les moteur=
s de=20
script, c'est qu'elle a =E9t=E9 pr=E9vue dans le langage, non ?
Merci,
Pascal
PS: =E7a marche aussi avec les objets du noyau !
(par exemple : var today =3D new Date)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Mickaël Wolff
Pascal a écrit :
Je me pose la question suivante : quelle est la véritable contrainte qui obligerait à utiliser des parenthèses, lorsqu'on crée un nouvel objet alors que le constructeur ne prévoie pas de passage d'arguments ?
Le problème est de savoir de quel objet tu parles.
var toto = function() { } // création d'un objet function var tutu = new toto ; // création d'un objet tutu prototypé à partir de l'objet toto.
Curieusement, je n'ai trouvé aucune doc ni tuto qui oserait proposer la deuxième syntaxe. Pourtant, si elle est tolérée par tous les moteurs de script, c'est qu'elle a été prévue dans le langage, non ?
La norme ecmascript (javascript est une implémentation de javascript) prévoit effectivement la syntaxe sans parenthèse avec new, mais la syntaxe de function requiert les parenthèses.
Je me pose la question suivante : quelle est la véritable contrainte qui
obligerait à utiliser des parenthèses, lorsqu'on crée un nouvel objet
alors que le constructeur ne prévoie pas de passage d'arguments ?
Le problème est de savoir de quel objet tu parles.
var toto = function() { } // création d'un objet function
var tutu = new toto ; // création d'un objet tutu prototypé à partir de
l'objet toto.
Curieusement, je n'ai trouvé aucune doc ni tuto qui oserait proposer la
deuxième syntaxe. Pourtant, si elle est tolérée par tous les moteurs de
script, c'est qu'elle a été prévue dans le langage, non ?
La norme ecmascript (javascript est une implémentation de javascript)
prévoit effectivement la syntaxe sans parenthèse avec new, mais la
syntaxe de function requiert les parenthèses.
Je me pose la question suivante : quelle est la véritable contrainte qui obligerait à utiliser des parenthèses, lorsqu'on crée un nouvel objet alors que le constructeur ne prévoie pas de passage d'arguments ?
Le problème est de savoir de quel objet tu parles.
var toto = function() { } // création d'un objet function var tutu = new toto ; // création d'un objet tutu prototypé à partir de l'objet toto.
Curieusement, je n'ai trouvé aucune doc ni tuto qui oserait proposer la deuxième syntaxe. Pourtant, si elle est tolérée par tous les moteurs de script, c'est qu'elle a été prévue dans le langage, non ?
La norme ecmascript (javascript est une implémentation de javascript) prévoit effectivement la syntaxe sans parenthèse avec new, mais la syntaxe de function requiert les parenthèses.
Le problème est de savoir de quel objet tu parles.
Cf. mon exemple.
var toto = function() { } // création d'un objet function
Forcément, c'est une syntaxe littérale de fonction (anonyme, en plus) . Moi, je parle d'objets créés à partir d'un constructeur avec le mot clé "new" (l'équivalent des instances de classes, quoi).
La norme ecmascript (javascript est une implémentation de ECMAScrip t*) prévoit effectivement la syntaxe sans parenthèse avec new, mais la syntaxe de function requiert les parenthèses.
(* j'ai corrigé)
Ok, pas de surprise jusque-là (hou ! ça va faire prétentieux, mais je suis pas vraiment débutant, alors on peut passer qqes étapes).
Bon, je reformule : d'accord, le standard prévoie cette syntaxe, mais alors pourquoi personne (sauf moi, des fois) ne l'emploie (ou ne montre qu'il l'emploie dans ses exemples) ? Y a-t-il une contrainte formelle (des moteurs à la con qui aimeraient pas) ou informelle (une convention d'écriture héritée de j'sais pas quoi) ?
En tout cas merci pour cette première réponse.
Cordialement, Pascal
Mickaël Wolff a écrit :
Le problème est de savoir de quel objet tu parles.
Cf. mon exemple.
var toto = function() { } // création d'un objet function
Forcément, c'est une syntaxe littérale de fonction (anonyme, en plus) .
Moi, je parle d'objets créés à partir d'un constructeur avec le mot clé
"new" (l'équivalent des instances de classes, quoi).
La norme ecmascript (javascript est une implémentation de ECMAScrip t*)
prévoit effectivement la syntaxe sans parenthèse avec new, mais la
syntaxe de function requiert les parenthèses.
(* j'ai corrigé)
Ok, pas de surprise jusque-là (hou ! ça va faire prétentieux, mais je
suis pas vraiment débutant, alors on peut passer qqes étapes).
Bon, je reformule : d'accord, le standard prévoie cette syntaxe, mais
alors pourquoi personne (sauf moi, des fois) ne l'emploie (ou ne montre
qu'il l'emploie dans ses exemples) ? Y a-t-il une contrainte formelle
(des moteurs à la con qui aimeraient pas) ou informelle (une convention
d'écriture héritée de j'sais pas quoi) ?
Le problème est de savoir de quel objet tu parles.
Cf. mon exemple.
var toto = function() { } // création d'un objet function
Forcément, c'est une syntaxe littérale de fonction (anonyme, en plus) . Moi, je parle d'objets créés à partir d'un constructeur avec le mot clé "new" (l'équivalent des instances de classes, quoi).
La norme ecmascript (javascript est une implémentation de ECMAScrip t*) prévoit effectivement la syntaxe sans parenthèse avec new, mais la syntaxe de function requiert les parenthèses.
(* j'ai corrigé)
Ok, pas de surprise jusque-là (hou ! ça va faire prétentieux, mais je suis pas vraiment débutant, alors on peut passer qqes étapes).
Bon, je reformule : d'accord, le standard prévoie cette syntaxe, mais alors pourquoi personne (sauf moi, des fois) ne l'emploie (ou ne montre qu'il l'emploie dans ses exemples) ? Y a-t-il une contrainte formelle (des moteurs à la con qui aimeraient pas) ou informelle (une convention d'écriture héritée de j'sais pas quoi) ?
En tout cas merci pour cette première réponse.
Cordialement, Pascal
Mickaël Wolff
Pascal a écrit :
var toto = function() { } // création d'un objet function
Forcément, c'est une syntaxe littérale de fonction (anonyme, en plus). Moi, je parle d'objets créés à partir d'un constructeur avec le mot clé "new" (l'équivalent des instances de classes, quoi).
En Ecmascript, il n'y a que des instances d'objets ;)
Ok, pas de surprise jusque-là (hou ! ça va faire prétentieux, mais je suis pas vraiment débutant, alors on peut passer qqes étapes).
Bon, je reformule : d'accord, le standard prévoie cette syntaxe, mais alors pourquoi personne (sauf moi, des fois) ne l'emploie (ou ne montre qu'il l'emploie dans ses exemples) ? Y a-t-il une contrainte formelle (des moteurs à la con qui aimeraient pas) ou informelle (une convention d'écriture héritée de j'sais pas quoi) ?
Moi aussi évite de mettre des parenthèses inutiles. Mais ça vient de mon expérience avec le C++ (prise en compte de operator () lorsqu'il n'y a pas de constructeur par défaut explicite). Alors, pourquoi tout les autres mettent des parenthèses ? Je suppose que c'est en raison de l'apprentissage. Les tutoriaux ne s'encombrent que rarement la syntaxe complète d'un langage (ce n'est pas leur role). Le problème c'est de rester au niveau des tutoriaux.
var toto = function() { } // création d'un objet function
Forcément, c'est une syntaxe littérale de fonction (anonyme, en plus).
Moi, je parle d'objets créés à partir d'un constructeur avec le mot clé
"new" (l'équivalent des instances de classes, quoi).
En Ecmascript, il n'y a que des instances d'objets ;)
Ok, pas de surprise jusque-là (hou ! ça va faire prétentieux, mais je
suis pas vraiment débutant, alors on peut passer qqes étapes).
Bon, je reformule : d'accord, le standard prévoie cette syntaxe, mais
alors pourquoi personne (sauf moi, des fois) ne l'emploie (ou ne montre
qu'il l'emploie dans ses exemples) ? Y a-t-il une contrainte formelle
(des moteurs à la con qui aimeraient pas) ou informelle (une convention
d'écriture héritée de j'sais pas quoi) ?
Moi aussi évite de mettre des parenthèses inutiles. Mais ça vient de
mon expérience avec le C++ (prise en compte de operator () lorsqu'il n'y
a pas de constructeur par défaut explicite). Alors, pourquoi tout les
autres mettent des parenthèses ? Je suppose que c'est en raison de
l'apprentissage. Les tutoriaux ne s'encombrent que rarement la syntaxe
complète d'un langage (ce n'est pas leur role). Le problème c'est de
rester au niveau des tutoriaux.
var toto = function() { } // création d'un objet function
Forcément, c'est une syntaxe littérale de fonction (anonyme, en plus). Moi, je parle d'objets créés à partir d'un constructeur avec le mot clé "new" (l'équivalent des instances de classes, quoi).
En Ecmascript, il n'y a que des instances d'objets ;)
Ok, pas de surprise jusque-là (hou ! ça va faire prétentieux, mais je suis pas vraiment débutant, alors on peut passer qqes étapes).
Bon, je reformule : d'accord, le standard prévoie cette syntaxe, mais alors pourquoi personne (sauf moi, des fois) ne l'emploie (ou ne montre qu'il l'emploie dans ses exemples) ? Y a-t-il une contrainte formelle (des moteurs à la con qui aimeraient pas) ou informelle (une convention d'écriture héritée de j'sais pas quoi) ?
Moi aussi évite de mettre des parenthèses inutiles. Mais ça vient de mon expérience avec le C++ (prise en compte de operator () lorsqu'il n'y a pas de constructeur par défaut explicite). Alors, pourquoi tout les autres mettent des parenthèses ? Je suppose que c'est en raison de l'apprentissage. Les tutoriaux ne s'encombrent que rarement la syntaxe complète d'un langage (ce n'est pas leur role). Le problème c'est de rester au niveau des tutoriaux.
En Ecmascript, il n'y a que des instances d'objets ;)
Ça ferait presque l'objet d'un autre fil, mais je crois que cette formule est un peu raccourcie, l'ami. ;-)
Sinon :
var str1 = "toto"; // et... var str2 = new String("toto");
...serait du même type, or ce n'est pas le cas :
var type1 = typeof str1; // 'string' var type2 = typeof str2; // 'object'
Et pourtant :
var uc1 = str1.toUpperCase(); // et... var uc2 = str2.toUpperCase();
...donne bien le même résultat, puisque traités comme des objets de même type auxquels est appliquée la même méthode !
Ce qui prouve que la déclaration de str1 n'a pas créé une instance d'objet, mais que celle-ci est temporairement créée lorsque nécessa ire (effet du typage dynamique).
Me trompe-je ?
Mickaël Wolff a écrit :
En Ecmascript, il n'y a que des instances d'objets ;)
Ça ferait presque l'objet d'un autre fil, mais je crois que cette
formule est un peu raccourcie, l'ami. ;-)
Sinon :
var str1 = "toto"; // et...
var str2 = new String("toto");
...serait du même type, or ce n'est pas le cas :
var type1 = typeof str1; // 'string'
var type2 = typeof str2; // 'object'
Et pourtant :
var uc1 = str1.toUpperCase(); // et...
var uc2 = str2.toUpperCase();
...donne bien le même résultat, puisque traités comme des objets de même
type auxquels est appliquée la même méthode !
Ce qui prouve que la déclaration de str1 n'a pas créé une instance
d'objet, mais que celle-ci est temporairement créée lorsque nécessa ire
(effet du typage dynamique).
En Ecmascript, il n'y a que des instances d'objets ;)
Ça ferait presque l'objet d'un autre fil, mais je crois que cette formule est un peu raccourcie, l'ami. ;-)
Sinon :
var str1 = "toto"; // et... var str2 = new String("toto");
...serait du même type, or ce n'est pas le cas :
var type1 = typeof str1; // 'string' var type2 = typeof str2; // 'object'
Et pourtant :
var uc1 = str1.toUpperCase(); // et... var uc2 = str2.toUpperCase();
...donne bien le même résultat, puisque traités comme des objets de même type auxquels est appliquée la même méthode !
Ce qui prouve que la déclaration de str1 n'a pas créé une instance d'objet, mais que celle-ci est temporairement créée lorsque nécessa ire (effet du typage dynamique).
Me trompe-je ?
Mickaël Wolff
Pascal a écrit :
Ça ferait presque l'objet d'un autre fil, mais je crois que cette formule est un peu raccourcie, l'ami. ;-)
Sinon :
var str1 = "toto"; // et... var str2 = new String("toto");
...serait du même type, or ce n'est pas le cas :
var type1 = typeof str1; // 'string' var type2 = typeof str2; // 'object'
Ce que je voulais exprimer, c'est que dans Ecmascript il n'existe pas de concept de class, mais uniquement d'objets. Les types de base se comportant comme des objets.
Ce qui prouve que la déclaration de str1 n'a pas créé une instance d'objet, mais que celle-ci est temporairement créée lorsque nécessaire (effet du typage dynamique).
Me trompe-je ?
Je pense que les chaines litérales sont strictement équivalentes aux objets créés à partir de la propriété String de l'objet hote. Je pense que l'essentiel est vraiment de ne pas faire de différence, et de profiter de l'abstraction du langage.
Ça ferait presque l'objet d'un autre fil, mais je crois que cette
formule est un peu raccourcie, l'ami. ;-)
Sinon :
var str1 = "toto"; // et...
var str2 = new String("toto");
...serait du même type, or ce n'est pas le cas :
var type1 = typeof str1; // 'string'
var type2 = typeof str2; // 'object'
Ce que je voulais exprimer, c'est que dans Ecmascript il n'existe pas
de concept de class, mais uniquement d'objets. Les types de base se
comportant comme des objets.
Ce qui prouve que la déclaration de str1 n'a pas créé une instance
d'objet, mais que celle-ci est temporairement créée lorsque nécessaire
(effet du typage dynamique).
Me trompe-je ?
Je pense que les chaines litérales sont strictement équivalentes aux
objets créés à partir de la propriété String de l'objet hote. Je pense
que l'essentiel est vraiment de ne pas faire de différence, et de
profiter de l'abstraction du langage.
Ça ferait presque l'objet d'un autre fil, mais je crois que cette formule est un peu raccourcie, l'ami. ;-)
Sinon :
var str1 = "toto"; // et... var str2 = new String("toto");
...serait du même type, or ce n'est pas le cas :
var type1 = typeof str1; // 'string' var type2 = typeof str2; // 'object'
Ce que je voulais exprimer, c'est que dans Ecmascript il n'existe pas de concept de class, mais uniquement d'objets. Les types de base se comportant comme des objets.
Ce qui prouve que la déclaration de str1 n'a pas créé une instance d'objet, mais que celle-ci est temporairement créée lorsque nécessaire (effet du typage dynamique).
Me trompe-je ?
Je pense que les chaines litérales sont strictement équivalentes aux objets créés à partir de la propriété String de l'objet hote. Je pense que l'essentiel est vraiment de ne pas faire de différence, et de profiter de l'abstraction du langage.
