Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

syntaxe...

11 réponses
Avatar
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

10 réponses

1 2
Avatar
Olivier Miakinen
Bonjour,

Le 23/07/2009 19:19, pserru a écrit :

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&gt;
[fr] <http://fr2.php.net/manual/fr/language.types.string.php&gt;

- 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&gt;
<http://fr2.php.net/manual/fr/language.variables.variable.php&gt;

- 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,
--
Olivier Miakinen
Avatar
Mickaël Wolff
Olivier Miakinen a écrit :

Le 23/07/2009 19:19, pserru a écrit :
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


Avatar
Xavier Nayrac
pserru a écrit :
- 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 ;)

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



jamais

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



jamais

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




occasionnellement

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.

--
Xavier Nayrac
http://personalbugtracker.free.fr
Avatar
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
Avatar
Olivier Miakinen
Le 25/07/2009 10:55, pserru a écrit :

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.

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



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

(et côté exécution ?)...



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

- "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&gt;
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().

--
Olivier Miakinen
Avatar
Xavier Nayrac
pserru a écrit :
- 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".



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

--
Xavier Nayrac
http://personalbugtracker.free.fr
Avatar
Olivier Miakinen
Le 25/07/2009 17:23, Xavier Nayrac a écrit :

"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.

Je pinaille, là ?



Oui. Plutôt. ;-)

--
Olivier Miakinen
Avatar
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
Avatar
Xavier Nayrac
Olivier Miakinen a écrit :
Le 25/07/2009 17:23, Xavier Nayrac a écrit :
"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.

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.

--
Xavier Nayrac
http://personalbugtracker.free.fr
Avatar
Olivier Miakinen
Le 25/07/2009 17:55, pserru a écrit :

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
d'une boucle infernale (-:



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
souviennent et me parait plus concis que /*2*/:
/*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.

De même:
/*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. ;-)

--
Olivier Miakinen
1 2