La question est dans le titre. P>
Je pense que la plupart d'entre nous, ce programme dans PHP a appris à Alors pourquoi avons-nous: p>
au lieu de p>
Et pourquoi les deux existent-ils et comportent-ils différemment? Y a-t-il une référence à la raison pour laquelle ce choix a été fait? P>
Les gens se réfèrent aux documents PHP indiquant que ECHO est une construction de langue et que celle-ci est utilisée différemment. Mais dans ce cas, puisque nous pouvons les utiliser comme une construction aswell que fonctionnel: qui est la méthode préférée? Et pourquoi a-t-il été mis en œuvre à la fois alors qu'il ne devrait s'agir que d'une construction de langue? P>
EDIT 2: strong> identique à celui ci-dessus à peu près beaucoup pour ECHO "String"; code>. Bien que commun, je me demande pourquoi nous utilisons cela si différent puis toute autre fonction. p>
echo "une chaîne"; code> p>
echo ("une chaîne"); code> p>
exiger code>, require_once code>, inclure code> et Inclure_once code>. Je ne trouve rien sur le Web expliquant - pourquoi ces constructions ont également été mises en œuvre fonctionnelles (et dans le cas d'écho (), d'une manière imparfaite). P>
3 Réponses :
de php.net em> strong> :
echo n'est pas en fait une fonction (c'est une construction de langue), donc vous ne sont pas tenus d'utiliser des parenthèses avec elle. P> blockQuote>
Si vous souhaitez passer plus d'un paramètre à ECHO, les paramètres ne doit pas être enfermé entre parenthèses. P> blockQuote>
Exemple fort> (à partir de
PHP 5.4.14 code>) : strong> p>xxx pré>
upvv1: strong> em> p>
Remarque: parce que ceci est une construction de langue et non une fonction, il ne peut pas être appelé à l'aide de fonctions variables. P> blockQuote>
xxx pré>
upvv2: strong> p> p>
AS de
inclure code>(identique s'applique àExiger code>,require_once code> etetInclure_once code>), il pourrait avoir un retour valeur em> < / fort>. Par exemple: p>filea.php: em> p>
xxx pré> fileb.php: em> p >
xxx pré> test: em> p>
xxx pré> montre: p>
xxx pré> Il a été mentionné sur < php.net em> strong> dans exemples
# 4 strong> et # 5 strong>. p> parce que les expressions telles que
incluent 'ok' == 'ok' code> sont Pas évident (selon Precedence de l'opérateur em> ) , vous devez les enfermer entre parenthèses ou utiliser une approche "Code" de type ":(Inclure 'Filea.PHP') == 'OK' CODE> ouInclure (" filea.php ') = = 'Ok' code>. P> p>
Meilleure réponse jusqu'à présent, merci@corrupt. Je me demande toujours pourquoi les développeurs ont rendu la "construction de langue" utilisable de manière fonctionnelle. Surtout que cela se comporte différemment. Est-ce juste un «fluke» dans l'historique PHP Dev? Ou était-il une bonne raison derrière cela?
@Damien Overeem, problèmes de capacité arrière, peut-être.
Semble que cela ne soit pas considéré comme une "vraie question". Ce qui est étrange si vous me demandez, mais quoi que ce soit. J'aurais aimé découvrir le raisonnement derrière ce comportement un peu strang ... Je vais accepter votre réponse, car elle a souligné la différence idiote entre les 2 méthodes.
@Damien Overeem j'ai mis à jour la réponse avec le test de fonction variable i> appel.
Belle prise. Rend l'existence de echo (); code> encore plus maladroit. Cela fonctionne, mais a un comportement inattendu total ...
@Damien Overeem mis à jour pour s'adapter aux exigences de Editer 2 B>.
Plutôt intéressant. Je ne savais même pas que vous pouviez retour code> dans un fichier incluant. Une chose plutôt méchante à utiliser réellement, mais intéressante à savoir.
@Damien Overeem Oui, je ne l'utilise pas aussi, mais une personne quelque part peut le faire de manière incompréhensible. Ce n'est pas Evul code> jusqu'à ce qu'il ne soit pas en mains incurvées.
de la DOCS PHP P>
echo n'est pas en fait une fonction (c'est une construction de langue), donc vous ne sont pas tenus d'utiliser des parenthèses avec elle. écho (contrairement à d'autres constructions de langue) ne se comporte pas comme une fonction, donc il ne peut pas toujours être utilisé dans le contexte d'une fonction. De plus, si vous voulez Pour réussir plus d'un paramètre à Echo, les paramètres ne doivent pas être enfermé entre parenthèses p> blockQuote>
Ce n'est pas un funcion, d'où pas de parenthèse p>
Parce qu'une déclaration (construction de langues) n'est pas une fonction. Par conséquent, différencier une fonction et une déclaration, il est utilisé comme celui-ci. P>
parce que
echo code> est une construction de langue, pas une fonctionJe préfère personnellement la version du support. Autant que je sache, la syntaxe différente vient du fait que l'écho n'est pas une vraie fonction
@Sprottenwels toute raison particulière de cela? Je trouve moins de caractères == moins bruit == meilleure lisibilité. I>
Je suis en train de mettre un peu à contrer les bowvotes. Je sais que c'est une question de préférence, mais sachant que le raisonnement qui n'entre pas d'utiliser des parenthèses est quelque peu utile pour améliorer votre propre.
@Deceze on se sent juste mal. Surtout sur de grandes chaînes multi-bordées, les parenthèses m'aident à garder une piste. En outre, je l'ai fait partout, dans chaque langue que j'ai jamais écrite. Peut-être que je suis un peu trop proche de ce problème: x
Je suis déçu Cette question était fermée. Peut-être commencer par le "pourquoi" était faux. La vraie question est à peu près: pourquoi la méthode fonctionnelle d'ECHO a-t-elle été inventée / mise en œuvre ... puisqu'il se comporte totalement bizarre.
Merci de voter pour une nouvelle ouverture à tous.
Je suggère de renommer la question avec
quelle différence entre ECHO avec des accolades et sans accolades code>, ou quelque chose comme ça pour le rendre plus facile accessible à la recherche de futurs visiteurs. Cette question posée très souvent.Pas une mauvaise idée. Modifié.
Merci. Je pense que vous venez de le rendre plus clarifié.