Explication de la syntaxe d'un code jQuery

[Damocorp]

Bonjour,

J'ai trouver ce code sur le net ( Source : L’effet machine à écrire ) :

[pastebin]H3LadqLx[/pastebin]


Pourriez-vus m'aider à traduire la ligne 18 de la syntaxe pour que je la comprenne svp ?
C'est un peu le principe de l'opérateur ternaire en php si j'ai bien compris. Mais je n'arrive pas à comprendre son fonctionnement.
En français cela donnerai :
Si opt existe en paramètre de la fonction typewriter, opt est égal au paramètre de la fonction typewriter ou delay = 65.

Mais je dois me tromper quelque part car à la ligne 13, c'est un tableau qui est appelé sous la forme de opt['delay'].
Je ne comprend pas pourquoi firebug ne me renvoie pas une erreur pour variable undefined.

[Plume]

opt est un objet. La ligne 18 dit : "Si opt est défini, alors on affecte la valeur opt à opt, ce qui équivaut à ne rien faire. Sinon, on lui donne des valeurs par défaut { 'delay': 65 }."

Ça équivaut au code suivant :

if (opt === void 0) {

  opt = { 'delay': 65 };

}

De plus, en JavaScript opt.delay, c'est le même appel que opt['delay'].

[Maks]

Souvent en Javascript pour gérer les paramètres optionnels on utilise un hash (ici "opt" pour "options") car on ne sait pas à l'avance combien de paramètres optionnels on aura, ce qui pause problème si on a un paramètre supplémentaire derrière les paramètres optionnels (ici callback).

PS : void 0 j'ai toujours trouvé ça très très laid Ca me rappelle les saloperies de <a href="javascript : void(0)"></a> beurk !

[Plume]

C'est vrai. Désolé, j'ai pris l'habitude d'écrire du Vanilla à la sauce CoffeeScript

if (opt === undefined) {

  opt = { 'delay': 65 };

}

D'ailleurs, hors-sujet, mais un fait amusant :

options? # => (typeof options !== "undefined" && options !== null)

  

options is undefined # => (options === void 0)

Je me serai attendu à ce que

options?

compile en

(options !== undefined && options !== null)

Vous savez si il y a une explication ?

Enfin, plutôt que

<a href="javascript : void(0)"></a>

J'étais plutôt du genre à mettre

<a href="javascript: return false;"></a>

C'était déjà moins méchant.

PS : Les gars, y a pas de syntaxe highlight pour CoffeeScript sur le forum ?

[Maks]

void 0 a l'avantage d'être plus court que undefined, c'est intéressant pour minifier.

La syntaxe est censée être valide JSLint donc je suppose qu'il y a une explication. Mais pour moi c'est la même chose aussi...

Moi ce qui m'étonne c'est :

if req.session.userId?

  res.render 'index/ui'

if (req.session.userId != null) {

    res.render('index/ui');

}

if req?.session.userId

  res.render 'index/ui'

if (typeof req !== "undefined" && req !== null ? req.session.userId : void 0) {

    res.render('index/ui');

}

!= null c'est un peu léger, c'est suffisant sachant que null == void 0 et null == undefined mais pourquoi avoir quitté le double égal ?

Bref le parfait HS là

La réponse : https://github.com/jashkenas/coffee-script/issues/1869

EDIT : Pour toi _who : http://eliperelman.com/blog/2011/07/12/c...undefined/
TL;DR undefined est une variable est peut être rédéfinie tandis que typeof... === "undefined" est plus "safe"

[Plume]

!= null c'est un peu léger, c'est suffisant sachant que null == void 0 et null == undefined mais pourquoi avoir quitté le double égal ?

Après avoir lu la réponse, ce que je ne sais pas c'est : Est-ce qu'à la compilation CoffeeScript sait si la variable comparée est dans le scope ? Si oui, fait-il le nécessaire, à savoir donc, utiliser typeof ?

Merci pour le lien vers la comparaison avec typeof au lieu de undefined. Je sais donc maintenant la différence. Dois-je en conclure que le code rendu par CoffeeScript est inconsistent ?

[Maks]

CoffeeScript sait que tu es dans le scope, car req.session.userId? est dans le contexte req.session et donc il se contente du test minimal userId != null

Pour req?.session.userId, CoffeeScript sait que req risques d'être dans le scope global, et donc il effectue le test complet.

C'est la même chose pour les variables d'instances / classiques :

a? => typeof... car a est dans le scope global
@a? => this.a != null car a est dans le contexte this

De ce côté ça n'est pas consistant en effet. Peut être qu'il y a une volonté de réduire le code Javascript (cf. undefined => void 0)

C'est comme ça que je le vois moi ^^

[Plume]

L'inconsistance que je soulevais était plutôt sur la comparaison dans un même scope.

if options?

  bla



if options is undefined

  blo

if (typeof options !== "undefined" && options !== null) {

  bla;

}



if (options === void 0) {

  blo;

}

options est dans les deux cas dans le même scope. Après, on dit que undefined est redéfinissable. Sauf que tu ne peux pas redéfinir undefined avec CoffeeScript.

[Maks]

Sauf que tu ne peux pas redéfinir undefined avec CoffeeScript

En pur CoffeeScript non, mais tu peux toujours :

`var undefined = foo`

Ce qui est débile je te l'accorde.

La manière "officielle" de faire c'est avec le ?, après qu'il y ait des équivalences c'est normal. C'est le cas dans tous les langages, j’appellerais pas ça de l'"inconsitance"

[Damocorp]

De plus, en JavaScript opt.delay, c'est le même appel que opt['delay'].

Comment opt peut-être un objet et un array ? A moins que opt['delay'] ne soit pas un array ?


Bien que le sujet va beaucoup plus loin que mes connaissance ( surtout quand ça passe par de l'anglais ), y'avais des trucs intéressant dedans mais j'ai pas su tout suivre.