Raccourcis eruby?

Community FR
1

salut a tous,

J’essaie de comprendre pourquoi on peut écrire

<% %w( layout theme ).each do |style| %>
<%= stylesheet_link_tag %>
<% end %>

Mais pas

<%= %w( layout theme ).each { |style| stylesheet_link_tag style } %>

Est ce un problème de syntaxe ou eruby ne permet pas de mettre un
control statement dans une instruction %= ?

cordialement,
mc

2

les 2 expressions ne sont pas identiques :

1ère fois : stylesheet_link_tag

2ème fois : stylesheet_link_tag style
Pas de paramètre pour la fonction stylesheet_link_tag. C’est voulu ?

3

<%= %w( layout theme ).each { |style| stylesheet_link_tag style } %>

Dans cette forme, tu demandes d’afficher le résultat de l’appel %w(
layout theme ).each { |style| stylesheet_link_tag style }. Or cet appel
renvoie simplement le tableau de départ, soit [“layout”, “theme”]

++

yk

Marc Chantreux a écrit :

4

Ah oui !

C’est vrai qu’on se fait sans arrêt piéger quand on vient de languages
où
les fonctions renvoient toujours le même type.

Voir doc de Kernel::block_given?

Exemple de pickaxe :

def try
if block_given?
yield
else
“no block”
end
end

try » “no block”
try { “hello” } »
“hello”

            try do
              "hello"

end

5

Plus précisément, Ruby renvoie le résultat de l’évaluation de la
dernière expression rencontrée, pas besoin d’expliciter un “return” si
ce n’est pas nécessaire (comme dans les langages fonctionnels - Ocaml
roxor).

++

yk

philippe lachaise a écrit :

6

Zut c’est parti tout seul !

Exemple de pickaxe :

def try
if block_given?
yield
else
“no block”
end
end

try => “no block”
try { “hello” } => “hello”

try do
“hello” => “hello”
end

mais
puts try { “hello” }
donnerait nil , donc n’affichearait rien

7

Plus précisément, Ruby renvoie le résultat de l’évaluation de la
dernière expression rencontrée, pas besoin d’expliciter un “return”

Encore un piège à c…, même si ça permet des raccourcis d’écriture
sympas.

Là où on se fait avoir c’est quand la dernière expression évaluée est au
beau milieu de la fonction.

C’est contraire au principe d’avoir un seul point d’entrée et un seul
point
de sortie bien identifiés.

Donc attention aux return cachés !

8

def toto( arg )
if arg < 0
“négatif mon Capitaine”
elsif arg == 0
“zéro la tête à toto”
else
“Affirmatif mon Colonel”
end
end

toto -1 => “négatif mon Capitaine”

Evidemment ici c’est lisible, mais si j’imbrique des if, des unless et
des
case sur plusieurs nieveaux bien malin qui peut dire au premier coup
d’oeuil où est la dernire expression évaluée.

On 12/8/06, Guillaume B.
[email protected]

9

Là où on se fait avoir c’est quand la dernière expression évaluée est au beau milieu de la fonction.

??? t’aurais un exemple ? j’ai du mal à voir pourquoi ce ne serait pas
systématiquement la dernière expression…

gUI

–
Pour la santé de votre ordinateur, préférez les logiciels libres !

Guillaume B. : (05 61) 19 40 65 / bureau S723

10

Evidemment ici c’est lisible…

… et encore (-:
Ok, je vois l’embrouille.

gUI

–
Pour la santé de votre ordinateur, préférez les logiciels libres !

Guillaume B. : (05 61) 19 40 65 / bureau S723

11

C’est pour celà que certains auteurs recommendent le return explicite,
même
si ça fait moins “Ruby Way”.

12

Marc :

Est ce un problème de syntaxe ou eruby ne permet pas de mettre un
control statement dans une instruction %= ?

ERb avec <%= %> demande une expression (au sens Ruby du terme)
qui renvoit un objet qu’ERb pourra convertir en String.

Donc on peut écrire :

<%= %w( layout theme ).map { |style| stylesheet_link_tag style
}.join("\n") %>

ou encore :

<%= %w( layout theme).inject(’’) { |acc, style| acc <<
stylesheet_link_tag(style) + “\n” } %>

On peut utiliser if/then/else ou case/when, unless…

<%= begin
“coucou”
end %>

<%= if connected?
“foo”
else
“bar”
end %>

<%= message=“coucou”; message %>

<%= ActiveRecord %>

<%= “inutile”
“coucou” %>

on peut tout faire :slight_smile:

РJean-Fran̤ois.

13

Philippe :

Plus précisément, Ruby renvoie le résultat de l’évaluation de la
dernière expression rencontrée, pas besoin d’expliciter un “return”

Encore un piège à c…, même si ça permet des raccourcis d’écriture sympas.

Là où on se fait avoir c’est quand la dernière expression évaluée est au
beau milieu de la fonction.

C’est contraire au principe d’avoir un seul point d’entrée et un seul point
de sortie bien identifiés.

Yen a qui programme avec ce principe ?

РJean-Fran̤ois.

14

Philippe :

toto -1 => “négatif mon Capitaine”

Evidemment ici c’est lisible, mais si j’imbrique des if, des unless et des
case sur plusieurs nieveaux bien malin qui peut dire au premier coup
d’oeuil où est la dernire expression évaluée.

  • Si on indente bien son code, ya pas de souci (et certains éditeurs de
    texte propose le folding)

  • Si on a tellement de niveaux d’indentation que la ligne de code ne
    commence qu’après la 80e colonne, il faut peut être envisager
    de refactoriser son code et de créer des "sous-"méthodes.
    (pas spécifique à Ruby)

  • On ne peut pas forcément savoir quelle est la dernière expression
    évaluée, seulement au runtime (supposons que ce soit l’utilisateur
    qui rentre le nombre pour arg).

    РJean-Fran̤ois.

15

:slight_smile:

J’ai pas de religion là dessus. Je pense qu’on doit faire des
compromis
entre lisibilité (== sécurité accrue) et concision.

C’est comme le default: dans le switch C, pas obligé mais des fois on
ripe.

Disons que si c’était moi qui allongeais les sous pour un dev j’aurais
tendeance à encourager le style explicite.

Mon sentiment : la concision est parfaitment adaptées à l’écriture de
DSL
(de même que le parenthèses optionnelles) mais à utiliser avec sobriété
sinon.

16

Philippe :

C’est pour celà que certains auteurs recommendent le return explicite, même
si ça fait moins “Ruby Way”.

Bah… si tu tiens vraiment au return explicite, ça peut s’arranger :slight_smile:

def toto( arg )
return (if arg < 0
“négatif mon Capitaine”
elsif arg == 0
“zéro la tête à toto”
else
“Affirmatif mon Colonel”
end)
end

-- Jean-François.