syntaxe...

[pserru]

Bonjour tous,

Je travail, pour le plaisir de réinventer la roue (-: , sur un
"parser" PHP. L'obligation d'approfondir la grammaire de PHP pour ce
faire m'a fait découvrir des particularités. Je me pose une question à
la quelle vous pouvez tous répondre!
- Connaiss(i)ez vous bien (avant) la différence entre les chaînes
commençant par "'" et celles commençant par '"' ?
- Connaiss(i)ez vous (avant) cette syntaxe $$indirection, l'utilisez
vous [régulièrement | occasionnellement | rarement | jamais] ? (moi <-
rarement)
- Connaiss(i)ez vous (avant) cette syntaxe ${'variable'}, l'utilisez
vous [régulièrement | occasionnellement | rarement | jamais] ? (moi <-
1 fois, si si!)
- Utilisez vous [régulièrement | occasionnellement | rarement |
jamais] la syntaxe du genre : "bla bla bla {$var[0]} bla bla" ?

J'ai constaté que ces syntaxes un peu particulières ne sont pas
nécessairement bien "prise en charge" par les éditeurs, du côté de la
coloration syntaxique. Je comprends, trouvant celles relatives au
caractères "{" et "}" un peu «tordues». C'est au moins le cas de Kate
(KDE - Linux).

Merci et bon courage à chacun,
Patrick

[Olivier Miakinen]

Bonjour,

Je travaille, pour le plaisir de réinventer la roue (-: , sur un
"parser" PHP. L'obligation d'approfondir la grammaire de PHP pour ce
faire m'a fait découvrir des particularités. Je me pose une question à
laquelle vous pouvez tous répondre!

D'accord, j'y vais.

- Connaiss(i)ez vous bien (avant) la différence entre les chaînes
commençant par "'" et celles commençant par '"' ?

Oui, pour l'essentiel.

Les chaînes entre « ' », il est assez facile de se rappeler leur
comportement dans tous les cas de figure, même si on peut se poser la
question pour les « \ » suivis d'autre chose que « ' » ou « \ ».
Exemple : '\n' est-il équivalent à 'n' ou à '\\n' ?

Les chaînes entre « " », c'est plus délicat et je ne prétends pas me
rappeler par cœur tous les cas (par exemple, que donnent "\v", "\a",
"\$", "\x20AC", "\x2019" ?)

Tu n'as pas parlé non plus des deux autres syntaxes, la syntaxe Heredoc
et la syntaxe Nowdoc.

Quoi qu'il en soit, inutile de tout connaître par cœur si on sait
retrouver la syntaxe dans la doc :
[en] <http://fr2.php.net/manual/en/language.types.string.php>
[fr] <http://fr2.php.net/manual/fr/language.types.string.php>

- Connaiss(i)ez vous (avant) cette syntaxe $$indirection, l'utilisez
vous [régulièrement | occasionnellement | rarement | jamais] ? (moi <-
rarement)

Je la connais depuis longtemps, mais je ne l'ai jamais utilisée. Je ne
parviens même pas à trouver un cas où elle puisse être préférable à
l'utilisation d'un tableau, éventuellement associatif.

Quoi qu'il en soit, au besoin la doc est là :
<http://fr2.php.net/manual/en/language.variables.variable.php>
<http://fr2.php.net/manual/fr/language.variables.variable.php>

- Connaiss(i)ez vous (avant) cette syntaxe ${'variable'}, l'utilisez
vous [régulièrement | occasionnellement | rarement | jamais] ? (moi <-
1 fois, si si!)

Jamais rencontré. Est-ce un synonyme de $variable ? Je ne trouve pas de
référence non plus dans la doc : où est-ce ?

En revanche, je connais bien sûr la syntaxe "...{$tableau['index']}..."
mais je ne me rappelle pas si je l'ai déjà utilisée. En général j'écris
plutôt "...$tableau[index]..." à la place (je parle du cas d'un tableau
associatif, pas d'un index numérique).

- Utilisez vous [régulièrement | occasionnellement | rarement |
jamais] la syntaxe du genre : "bla bla bla {$var[0]} bla bla" ?

Oui, ça m'est sûrement déjà arrivé avec un index numérique.

J'ai constaté que ces syntaxes un peu particulières ne sont pas
nécessairement bien "prise en charge" par les éditeurs, du côté de la
coloration syntaxique. Je comprends, trouvant celles relatives au
caractères "{" et "}" un peu «tordues». C'est au moins le cas de Kate
(KDE - Linux).

Désolé, là je n'ai pas d'expérience : jusqu'à présent j'ai toujours
utilisé vim sans coloration syntaxique pour éditer les fichiers PHP.
Mais, en effet, les règles doivent être un peu ardues à écrire. ;-)

Cordialement,

[Mickaël Wolff]

Je travaille, pour le plaisir de réinventer la roue (-: , sur un
"parser" PHP. L'obligation d'approfondir la grammaire de PHP pour ce
faire m'a fait découvrir des particularités. Je me pose une question à
laquelle vous pouvez tous répondre!

J'espère que tu es déjà bien versé dans l'écriture d'un parser. C'est
tout sauf simple. Mais pourquoi ne lis-tu donc pas les sources bison qui
décrivent déjà la grammaire ? :D (c'est ironique, c'est illisible le
bison).

Quoi qu'il en soit, inutile de tout connaître par c�"ur si on sait

Je ne suis pas trop d'accord. PHP est un langage très automatique,
très piégeux. Et vu que tout ce qui concerne les tableaux et les chaînes
de caractère est au c�"ur de tout développement PHP, je pense qu'il faut
absolument tout faire pour être incollable sur ces types de données et
les fonctions associées.

Désolé, là je n'ai pas d'expérience : jusqu'à présent j'ai toujours
utilisé vim sans coloration syntaxique pour éditer les fichiers PHP.
Mais, en effet, les règles doivent être un peu ardues à écrire. ;-)

Malheureux ! La coloration syntaxique de PHP dans vim est tip top.
Les différentes saveurs de chaînes sont correctement interprétées. Et
pour ceux qui font beaucoup de requêtes SQL, la coloration syntaxique
des chaînes peut être appréciable.

[Jean-Baptiste Camille Bourgoin]

Post by Olivier Miakinen
Bonjour,

Post by pserru
(...)
- Connaiss(i)ez vous (avant) cette syntaxe $$indirection, l'utilisez
vous [régulièrement | occasionnellement | rarement | jamais] ? (moi <-
rarement)

Je la connais depuis longtemps, mais je ne l'ai jamais utilisée. Je ne
parviens même pas à trouver un cas où elle puisse être préférable à
l'utilisation d'un tableau, éventuellement associatif.
(...)

N'est-ce pas un héritage des déréférenceurs de Perl ?

$machin = "bidule" ;
$bidule = \$machin ;
$truc = $$bidule;
print $truc;
#=> bidule

Même en perl je ne suis pas certain qu'elle soit bien utile (sauf cas
particuliers) puisque l'opérateur flèche existe.

Post by Olivier Miakinen
Cordialement,

[Xavier Nayrac]

Post by pserru
- Connaiss(i)ez vous bien (avant) la différence entre les chaînes
commençant par "'" et celles commençant par '"' ?

Il me semble, enfin à peu près. Sans certitudes, quoi ;)

Post by pserru
- Connaiss(i)ez vous (avant) cette syntaxe $$indirection, l'utilisez
vous [régulièrement | occasionnellement | rarement | jamais] ? (moi <-
rarement)

jamais

Post by pserru
- Connaiss(i)ez vous (avant) cette syntaxe ${'variable'}, l'utilisez
vous [régulièrement | occasionnellement | rarement | jamais] ? (moi <-
1 fois, si si!)

jamais

Post by pserru
- Utilisez vous [régulièrement | occasionnellement | rarement |
jamais] la syntaxe du genre : "bla bla bla {$var[0]} bla bla" ?

occasionnellement

Post by pserru
J'ai constaté que ces syntaxes un peu particulières ne sont pas
nécessairement bien "prise en charge" par les éditeurs, du côté de la
coloration syntaxique. Je comprends, trouvant celles relatives au
caractères "{" et "}" un peu «tordues». C'est au moins le cas de Kate
(KDE - Linux).

Pour info sous netbeans 6.7 : coloration syntaxique nickel.

[pserru]

Merci Olivier, Mickaël et Xavier,

Pour Olivier, comme dit Mickaël, dommage que ton VIM ne colore pas. Le
mien aussi, colore, mais je ne sais pas s'il le fait bien. De ce que
j'ai vu, c'est moins bien que Kate (nombre de caratères limités de la
ligne...).

Merci Xavier pour ta concision. Je crois bien que tes réponses sont
tout à fait dans la moyenne!

En fait, ce que je trouve "croche", c'est que l'accolade a trois
"sens":
- Debut(fin) de bloc, classique, comme en C et autres
- Insertion de valeur courante d'une variable, dans une chaîne en '"',
donc, pour Olivier:
"bla bla {$tableau[$indice]} bla bla" est l'équivalent de "bla bla ".
$tableau[$indice]." bla bla". Bénéfice: deux caractères côté source
(et côté exécution ?)...
- "Insertion" du nom de la variable dans ${'variable'}. À l'intérieur
de ces accolades, PHP attend une expression dont le résultat doit être
une chaîne. C'est un peu déroutant mais assez intéressant... Il y a
une certaine cohérence, tout de même puisque derrière le $ signifiant
"variable", suit une chaîne, au moins dans la source, et cela colle
avec l'indirection de $$indirection car $indirection doit contenir une
chaîne... (heuuu... je suis clair ?)

Merci et bon courage à chacun,
Patrick

[Olivier Miakinen]

Post by pserru
Pour Olivier, comme dit Mickaël, dommage que ton VIM ne colore pas.

Vu que je m'arrange pour programmer toujours de la façon la plus lisible
possible, je n'ai jamais ressenti le besoin d'une colorisation du texte.
Au contraire, je suis gêné par l'alternance de couleurs dans tous les
coins, même si je suis bien conscient que c'est juste une question
d'habitude.

Post by pserru
"bla bla {$tableau[$indice]} bla bla" est l'équivalent de "bla bla ".
$tableau[$indice]." bla bla". Bénéfice: deux caractères côté source

Note bien que ce n'est pas cette syntaxe-là qui me posait question, mais
la syntaxe ${'variable'}.

Post by pserru
(et côté exécution ?)...

On s'en fout : c'est forcément insignifiant. À ce niveau, seule compte
la lisibilité du code.

Post by pserru
- "Insertion" du nom de la variable dans ${'variable'}. À l'intérieur
de ces accolades, PHP attend une expression dont le résultat doit être
une chaîne. C'est un peu déroutant mais assez intéressant... Il y a
une certaine cohérence, tout de même puisque derrière le $ signifiant
"variable", suit une chaîne, au moins dans la source, et cela colle
avec l'indirection de $$indirection car $indirection doit contenir une
chaîne... (heuuu... je suis clair ?)

Voilà, c'est exactement cette syntaxe que je ne connais pas. Surtout, je
ne vois pas ce qu'elle pourrait apporter :
- soit ${'variable'} signifie $variable et je ne vois pas pourquoi ne
pas écrire tout simplement $variable ;
- soit ${'variable'} sert à l'indirection du genre de $$variable et ça
fait partie des constructions que j'ai toujours évitées.

En relisant la doc j'ai l'impression que c'est le premier cas, mais en
utilisant une syntaxe décrite dans le second :
<cit. http://fr3.php.net/manual/en/language.variables.variable.php>
echo "$a ${$a}";
</cit.>

C'est donc une syntaxe dont je pense que je peux très bien m'en passer,
tout comme la fonction eval().

[pserru]

Salut tout le monde,
Je trouve la remarque d'Olivier relative à la coloration
syntaxique intéressssante. Je me suis souvent demandé pourquoi
j'appréciais tant PHP. Dans les raisons il y avait cette particularité
relative aux variables qui permet justement de les localiser
facilement par la couleur au moment de l'édition...

On s'en fout : c'est forcément insignifiant...

Hahaha... TU t'en fous. Les siècles ne sont-ils pas composées de temps
insignifiants, et les programmes d'instructions insignifiantes ? J'ai
mis un point d'interrogation pour ce qui n'était pas une question, et
j'aurais
dû écrire: je ne sais pas ce qu'il en est côté éxécution, mais il y a
fatalement une incidence... Cependant, sur ce point précis, je m'en
fous aussi, s'il ne s'agit pas du cas très rare de l'optimisation
d'une boucle infernale (-:

Ce caractère '{' dans une variable est une ressource du langage.
On en fait donc ce que l'on veut.
La notion de lisibilité est relative au lecteur. Je suppose que
tu veux dire: "Je m'arrange pour que mes programmes soient lisibles
par tous, y compris les moins avancés, ou moi-même, un lendemain de
fête...".
/*1*/ est très lisible pour ceux qui utilisent beaucoup ou se
souviennent et me parait plus concis que /*2*/:
/*1*/ expression ? expressionT : expressionF ;
/*2*/ if (expression) expressionT; else expressionF;
De même:
/*1*/ $ou_exclusif = !expr1 ^ !expr2;
/*2*/ $ou_exclusif = (expr1 && !expr2) || (!expr1 && expr2);
C'est mon dernier post sur ce sujet. Ce petit sondage risque de
virer Troll! Merci pour vos réponses, et bon courage à chacun,
Patrick

[Olivier Miakinen]

On s'en fout : c'est forcément insignifiant...

Hahaha... TU t'en fous. [...] il y a
fatalement une incidence...

Bien sûr, qu'il y a une incidence, je ne dis pas le contraire ! Je dis
juste qu'elle est forcément insignifiante, un peu comme le choix entre
guillemets simples et guillemets doubles pour les chaînes constantes.

Je précise tout de suite que je ne rentrerai pas plus qu'il y a quelques
jours dans ce marronnier. Relire les articles passés pour retrouver la
page de tests montrant que c'est... insignifiant.

Cependant, sur ce point précis, je m'en
fous aussi, s'il ne s'agit pas du cas très rare de l'optimisation

Ah ben nous sommes d'accord.

Ce caractère '{' dans une variable est une ressource du langage.
On en fait donc ce que l'on veut.

Je me dois de le reconnaître. De ton côté, reconnais que la syntaxe
${'variable'} est à la fois plus rare et plus complexe que $variable ;
il me semble préférable d'utiliser celle-ci plutôt que celle-là.

De la même façon, bien que l'écriture 12["0123456789ABCDEF"] soit
parfaitement valide en C, et équivalente à "0123456789ABCDEF"[12],
cette dernière est quand même préférable à l'autre.

La notion de lisibilité est relative au lecteur.

Dans une certaine mesure, oui. Mais dans une certaine mesure seulement.

Je suppose que
tu veux dire: "Je m'arrange pour que mes programmes soient lisibles
par tous, y compris les moins avancés, ou moi-même, un lendemain de
fête...".
/*1*/ est très lisible pour ceux qui utilisent beaucoup ou se
/*1*/ expression ? expressionT : expressionF ;
/*2*/ if (expression) expressionT; else expressionF;

Excellent exemple de « lisibilité relative au lecteur » : je fais partie
de ceux qui trouvent /*1*/ très lisible, mais je sais que d'autres y
sont complètement réfractaires.

/*1*/ $ou_exclusif = !expr1 ^ !expr2;
/*2*/ $ou_exclusif = (expr1 && !expr2) || (!expr1 && expr2);

Ici, l'un comme l'autre me semblent également peu lisibles, du moins si
l'on considère que expr1 et expr2 sont des entiers quelconques que l'on
veut assimiler à faux s'ils valent 0 et à vrai s'ils valent n'importe
quoi d'autre (1000, -3, 1, 0x7fffffff, etc.). Je suppose que c'est bien
ça que tu avais en tête, parce que si expr1 et expr2 sont déjà des
booléens la syntaxe la plus simple est la suivante :
/*3*/ $ou_exclusif = expr1 ^ expr2;

Note qu'avec l'hypothèse d'entiers quelconques à convertir en booléens
il y a aussi une syntaxe plus claire que /*1*/ et /*2*/. C'est :
/*4*/ $ou_exclusif = ((boolean)expr1) ^ ((boolean)expr2);
Voire :
/*5*/
$bool1 = (boolean)expr1; // On s'assure que l'on a des booléens
$bool2 = (boolean)expr2;
$ou_exclusif = $bool1 ^ $bool2; // maintenant on peut faire le xor

C'est mon dernier post sur ce sujet. Ce petit sondage risque de
virer Troll!

Ok. ;-)

[Xavier Nayrac]

Post by pserru
- Insertion de valeur courante d'une variable, dans une chaîne en '"',
"bla bla {$tableau[$indice]} bla bla" est l'équivalent de "bla bla ".
$tableau[$indice]." bla bla".

Plutôt équivalent de 'bla bla ' . $tableau[$indice] . ' bla bla'
Non ? Je pinaille, là ?

[Olivier Miakinen]

Post by Xavier Nayrac

Post by pserru
"bla bla {$tableau[$indice]} bla bla" est l'équivalent de "bla bla ".
$tableau[$indice]." bla bla".

Plutôt équivalent de 'bla bla ' . $tableau[$indice] . ' bla bla'

Pourquoi « plutôt » ? Ton écriture est *aussi* équivalente aux deux
premières. Je la trouve juste un peu plus lisible grâce aux espaces
dont tu as entouré les points de concaténation.

Post by Xavier Nayrac
Je pinaille, là ?

Oui. Plutôt. ;-)

[Xavier Nayrac]

Post by Olivier Miakinen

Post by Xavier Nayrac

Post by pserru
"bla bla {$tableau[$indice]} bla bla" est l'équivalent de "bla bla ".
$tableau[$indice]." bla bla".

Plutôt équivalent de 'bla bla ' . $tableau[$indice] . ' bla bla'

Pourquoi « plutôt » ? Ton écriture est *aussi* équivalente aux deux
premières. Je la trouve juste un peu plus lisible grâce aux espaces
dont tu as entouré les points de concaténation.

Post by Xavier Nayrac
Je pinaille, là ?

Oui. Plutôt. ;-)

Les espaces sont une habitude, effectivement pour la lisibilité, mais ce
n'était pas le propos ici.
Je voulais simplement attirer l'attention sur les guillemets simple ou
au lieu des doubles.
S'il n'y a pas de variable à substituer, pas besoin de guillemets double.
Voilà, c'était juste ça.