Variable dans les chaînes

Bonjour,
quand on inclus des variables dans les chaînes, il y a qqch que je ne comprends pas. Si par exemple je définis :

Code:

---

$titre = $_SESSION['title'];

---

la variable de session contient une chaîne. Alors

Code:

---

echo "ici c'est le $titre<BR>";

---

fonctionne bien, car le caractère < informe le parser sans ambiguïté que le nom de variable s'arrête là, bon.
Mais si j'écris

Code:

---

echo "ici c'est le $_SESSION['title']<BR>";

---

là j'obtiens le message

Citation:

---

syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE

---

. Pourquoi est-ce que là le parser proteste ?
Il faut carrément faire

Code:

---

echo "ici c'est le {$_SESSION['title']}<BR>";

---

La ceinture et les bretelles ?

D'autres syntaxes possibles :

Code:

---

echo "ici c'est le $_SESSION[title]<BR>";

---

Code:

---

echo 'ici c\'est le ' . $_SESSION['title'] . '<BR>';

---

Je ne pense pas qu'il y ait une motivation derrière ça. Le parser est construit comme ça, c'est tout.

Citation:

---

Le parser est construit comme ça, c'est tout.

---

Eh ben c'est pas fort de la part des développeurs :-(

Merci.

Salut,

il y a une bonne raison derrière la ceinture et les bretelles : c'est la possibilité d'injecter directement des formes complexes au sein des chaînes de caractères, en particulier des classes avec leurs méthodes.

Code:

---

$text = "texte de test {$instance->method(...)} fin de texte";

---

D'ailleurs, la notation {$ possède un token spécifique dans le parser PHP : T_CURLY_OPEN.

Pour te finir, les notations heredoc et nowdoc sont très pratiques et surtout bien plus performantes que l'inclusion de fichiers, avec une telle approche, l'injection de formats complexes au sein de la vue prend tout son sens. :ccool:

oui mais cela n'explique pas pourquoi on ne peut pas écrire

Code:

---

"$foo['y']"

---

Citation:

---

Envoyé par rawsrc

les notations heredoc et nowdoc sont très pratiqu

---

En effet, et c'est ce que j'utilise, mais quand je pose une question dans un forum, j'essaie toujours de circonscrire le problème à sa plus simple expression.

Citation:

---

Envoyé par sabotage

oui mais cela n'explique pas pourquoi on ne peut pas écrire

Code:

---

"$foo['y']"

---

---

C'est en effet ce qu'on dit ici : http://php.net/manual/fr/language.types.array.php

Code:

---

1 2 3 4 5

// Ceci ne fonctionnera pas, et en résultera une erreur d'analyse, comme ceci : // Parse error: parse error, expecting T_STRING' or T_VARIABLE' or T_NUM_STRING' // Ceci arrive lors de l'utilisation d'une supergloables dans les chaînes print "Hello $arr['fruit']"; print "Hello $_GET['foo']";

---

Mais on n'explique pas pourquoi. En fait, la notation $arr[fruit] n'est qu'une tolérance en l'absence de constante « fruit » pour remplacer $arr['fruit'] qui serait la notation rigoureuse, mais on se demande bien pourquoi la notation rigoureuse n'est pas accepté dans les chaînes ?
C'est comme si en français l'expression « cela dit » devenait une faute de français sous prétexte que « ceci dit » est largement toléré bien qu'erroné.

Citation:

---

C'est comme si en français l'expression « cela dit » devenait une faute de français sous prétexte que « ceci dit » est largement toléré bien qu'erroné.

---

Dans une langue, il n'y a qu'une chose de vraie, c'est l'usage qu'en font les locuteurs.
A l'inverse dans une langue informatique, c'est le concepteur qui donne les règles et on ne peut pas en déroger.

Citation:

---

Envoyé par sabotage

oui mais cela n'explique pas pourquoi on ne peut pas écrire

Code:

---

"$foo['y']"

---

---

Pièce jointe 204236

Par ce que si tu autorise ça, alors pourquoi pas "$foo["y"]". Et la ça deviens ambiguë.

Le parseur s'attend a un T_STRING ou à un T_VARIABLE et T_NUM_STRING mais pas à un T_CONSTANT_ENCAPSED_STRING.

Mais, bonne nouvelle, rien ne t’empêche d'ajouter l'alternative T_CONSTANT_ENCAPSED_STRING à la grammaire PHP. Ca va ralentir un peu l’analyseur mais tu pourra faire des copier collé (enfin a moitié, par ce que pas quand il y a des double-quote).

Du coup ca entraîne la question :

Citation:

---

Pourquoi est-ce que là le parser proteste ?

Code:

---

"$foo['y'.$baz]"

---

---

Là le développeur que tu es se dit je vais ajouter un T_PAAMAYIM_NEKUDOTAYIM et doucement l'analyseur va commencer a tourner en boucle récursivement. Les développeurs autour de toi ne vont plus comprendre le code PHP de complexité 10 que tu va écrit et une licorne va mourir :calim2:

Pièce jointe 204234

Je n'ai vraiment pas l'impression d'avoir été giflé par Obelix suite à ta démonstration.

Citation:

---

Par ce que si tu autorise ça, alors pourquoi pas "$foo["y"]". Et la ça deviens ambiguë.

---

Parce ca ne suit pas la logique d'imbrication d'un texte ni en langage naturelle ni en langage informatique.
De plus permettre quelque chose de simple n'implique pas d'autoriser ni autre chose de simple ni autre chose de compliqué.
Par exemple on ne peut pas écrire "il dit : "bonjour"" mais on peut écrire "il dit : 'bonjour'"

Citation:

---

"$foo['y'.$baz]"

---

La c'est bien expliqué dans la documentation, quand on veut des écritures complexes, le parser a des limites, on utilise {}
Mais le sujet de base c'était de se demander pourquoi une écriture a priori plus simple à comprendre pour le parser (la clef est encadré) et identique à l'écriture en dehors d'une chaine, n'est pas prise en compte.

Enfin moi personnellement ça ne m'empêche pas de dormir ni d'écrire du code.

Citation:

---

Envoyé par sabotage

Dans une langue, il n'y a qu'une chose de vraie, c'est l'usage qu'en font les locuteurs.

---

Non, ça c'est l'excuse que se donnent ceux qui parlent mal ;-)
Je regrette, mais les fautes de français ça existe.
Je suis d'accord que l'usage fini par inventer de nouvelles tournures, mais jamais les anciennes ne deviennent des fautes.